Re: Review of LKST probe points

["Frank Ch. Eigler" <fche at redhat dot com>]

Hi -


> [...]. Spinlocks are something that people are really interested in.
> Will probably want more control than instrumenting all the spinlocks
> or none of the spinlocks. [...]  It would make sense to be able to
> put instrumentation based based on the lock variable [...]  Maybe
> use the debug registers that monitor a memory location to help with
> that.

Unfortunately I suspect doing this would require full first-class
probes, coded to check the lock variable and return early.


> >[...]
> >Can you outline what these are for?
> 
> Some of the LKST_ operations are for management of LKST. There events 
> are listed in lkst-events-2.1.pdf. [...]
> [...]

I guess I don't understand what "management of LKST" means.


> [...]  It would be nice if the probe could be [placed] inside the
> spinlock region of the instrumented code. This would ensure that
> data is gathered and minimize perturbations by attempting to get the
> lock twice.

That's true.  In case it's not clear though, sometimes we may have to
traverse a lock-protected data structure from a routine that is not
involved directly with it, like a timer interrupt.  It is possible not
lock these data structures from within a probe that's traversing them,
but that of course risks reading junk data on SMP.


- FChE

Attachment: pgp00000.pgp
Description: PGP signature