Re: runtime committed to cvs

[Martin Hunt <hunt at redhat dot com>]

On Wed, 2005-03-09 at 18:18 -0500, Frank Ch. Eigler wrote:

> The hash tables rely greatly on dynamic memory allocation, for nodes
> as well as individual string objects.  

No.  Only strings are normally allocated dynamically. There is an option
to have nodes allocated dynamically, which I put in to test future
memory allocation code. We can also easily have strings use that code.

> As mentioned before, this is
> not appropriate in the context of an embedded probe that could easily
> gobble up GFP_ATOMIC memory.  I believe support for preallocation of
> such data, including strings, is critical.  

Currently only small amounts of memory (the length of a string or two)
are allocated using GFP_ATOMIC.  All the memory allocations are written
to be able to plug in a different allocation system later.  For now this
hasn't been a problem.

> (This may require changes
> to its style of passing/returning string values by pointer-reference.)
> OOM handling should be left to the caller.

That gets ugly fast.  I thought it better to have global handling of OOM
situations.  Really we only have two options, record an OOM situation
was seen and either continue (with loss of data) or exit.

> Your tests don't include any mutual exclusion primitives, even though
> your hashtable operations are stateful call sequences.  This may work
> for now, as the kprobes layer has a Big Lock of its own, but we should
> not count on this limitation persisting too long.  You might entertain
> treating the runtime as a user-level library, and writing a
> multi-threaded testsuite for it to give it a more thorough workout.

That's a good idea.  I have thought about the locking problems and
decided to not implement anything until I could test them.

Martin