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: Some notes on translation


Martin Hunt writes:
 > On Fri, 2005-02-25 at 12:09 -0600, Tom Zanussi wrote:
 > 
 > Supporting that has caused me some real headaches.  I originally didn't
 > want to support arbitrary-size strings as hash keys because of the
 > memory management problems.  The simple way to do this is to kmalloc
 > (GFP_ATOMIC) for memory to save the string in, but we don't want to do
 > that.  Not doing it means preallocating a large static buffer and
 > allocating memory out of it for string storage. That is what I have
 > implemented so far.  Unfortunately it does not actually free memory that
 > is no longer used, so if keys change frequently, it will waste memory.
 > I think this will probably not be the normal case.
 > 
 > I think I will probably end up adding a malloc lib into the
runtime.

Just a thought - maybe you could keep a dynamic array of pages that
you allocate and free as necessary using get_free_pages(GFP_KERNEL) in
a work queue or something.  You could keep a minimal number around at
all times, and if you reach a point where the current set is say
half-filled, you could fire off another background allocation and hope
that they got allocated before you needed them.  Something along these
lines might be possible anyway.  Of course you wouldn't want to let
this get out of hand... ;-)

Tom


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