This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: [PATCH] kprobes for s390 architecture
- From: fche at redhat dot com (Frank Ch. Eigler)
- To: Mike Grundy <grundym at us dot ibm dot com>
- Cc: Heiko Carstens <heiko dot carstens at de dot ibm dot com>, Martin Schwidefsky <schwidefsky at de dot ibm dot com>, Jan Glauber <jan dot glauber at de dot ibm dot com>, systemtap at sources dot redhat dot com, dwilder at us dot ibm dot com
- Date: 10 Jul 2006 11:51:09 -0400
- Subject: Re: [PATCH] kprobes for s390 architecture
- References: <20060623150344.GL9446@osiris.boeblingen.de.ibm.com> <OF44DB398C.F7A51098-ON88257196.007CD277-88257196.007DC8F0@us.ibm.com> <20060623222106.GA25410@osiris.ibm.com> <20060624113641.GB10403@osiris.ibm.com> <1151421789.5390.65.camel@localhost> <20060628055857.GA9452@osiris.boeblingen.de.ibm.com> <20060707172333.GA12068@localhost.localdomain> <20060707172555.GA10452@osiris.ibm.com> <20060708185428.GA26129@localhost.localdomain> <y0mmzbha660.fsf@ton.toronto.redhat.com>
I wrote:
> grundym wrote:
> > I'll have to do some timing tests to measure how much overhead it
> > puts on the system. It's a trade off of safety vs speed. [...]
>
> No question, safety has to be paramount.
To elaborate: safety here would mean system stability. If a method of
probe insertion/removal can be found that does not risk stability,
merely may cause unpredictable early/late probe hits, or gradual
deferred cleanup that would be fine. For example, it may likely be
fine if different processors on an SMP start or stop to see the kprobe
breakpoints at different times. A "softer" method analogous to RCU
may work for us here.
- FChE