This is the mail archive of the
systemtap@sources.redhat.com
mailing list for the systemtap project.
RE: Hitachi djprobe mechanism
- From: "Keshavamurthy, Anil S" <anil dot s dot keshavamurthy at intel dot com>
- To: "Roland McGrath" <roland at redhat dot com>
- Cc: "Mathieu Desnoyers" <compudj at krystal dot dyndns dot org>, "Andi Kleen" <ak at suse dot de>, "Karim Yaghmour" <karim at opersys dot com>, "Masami Hiramatsu" <masami dot hiramatsu at gmail dot com>, "Masami Hiramatsu" <hiramatu at sdl dot hitachi dot co dot jp>, "Richard J Moore" <richardj_moore at uk dot ibm dot com>, <systemtap at sources dot redhat dot com>, <sugita at sdl dot hitachi dot co dot jp>, "Satoshi Oshima" <soshima at redhat dot com>, <michel dot dagenais at polymtl dot ca>
- Date: Mon, 1 Aug 2005 15:39:57 -0700
- Subject: RE: Hitachi djprobe mechanism
>It's OK for probe insertion to be slow.
Yes, slow is okay as long as you are *not* taking the full
system down during probe inserting/removal time. Halting full
system during probe insertion/removal might not be acceptable
at least on IA64.
>So why not use RCU to
>synchronize
>other processors?
The thing here is while we are trying to modify the section of code say
couple of instructions to accommodate 5 bytes(jmp inst), during this
period
we don't want any cpu to be in the middle of this area and to be
*really*
sure they(other CPU's) don't get half backed instruction, we must
place all of the other CPU's in a known location. So in this scenario,
I doubt how RCU synchronization can help.
If I am wrong please educate me.
Cheers,
-Anil