This is the mail archive of the systemtap@sources.redhat.com mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: SystemTap Kernel Runtime Library


Hi -


> [...]
> DETAILS
> Initially I plan to support only the following key types:
> [...]

Heh, you found my #define-based templating a bit too distasteful, eh?


> The values stored in the arrays can be the following:
> 64-bit int [...]

what is the sense of the wider audience about whether we should pick
the native "long" (32 or 64 bits) or a fixed 64-bit data type, for
all numeric values?  (Like dtrace, I'd like to pick just one.)


> There will be functions to lookup a value, change a value, clear an
> array, print an array, and walk an array. 

We'd also want a "delete array entry" operation.

Regarding walking and concurrency.  I envision generally having
per-global-variable spinlocks for mutual exclusion, assuming IBM 
overcomes kprobes' single-threadedness.  (If not, all such locking
is unnecessary.)  This should work all right, for plain get/set
operations.  For walking it's not enough, since we may not want
to casually hold a lock on the entire array as an arbitrary nested
block of code is being run.

Related to this is the notion that while an array is being walked
(using an awk-like "for (var in array) {...}" syntax), it should
not be modifiable in such a way that interferes with the traversal.
One benefit of parsing the probe script is that we can statically
detect such attempts and block or otherwise defang them.


> [...]
> These arrays need to be resident in kernel memory.  This means we need 
> to be careful how many we allocate.  Allocation can be done at runtime,
> but if we run out of empty array members, we will need to kmalloc()
> more, truncate, or fail.  [...]

In particular, you could likely need kmalloc (GPF_ATOMIC), which is
considered scarce too.  We would not want one runaway systemtap
probe function to be able to use up all the emergency atomic memory.
I believe a non-atomic heap allocation done at module_init time, or
even a static one done within the emitted C function, even if covering
several megabytes, would be okay.


- FChE

Attachment: pgp00000.pgp
Description: PGP signature


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]