This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: offline elfutils processing committed
Martin Hunt <hunt@redhat.com> writes:
> [...]
> > It however exposes two problems with the newest symbol table code.
> > First, the new _stp_module_lookup function holds a spinlock on its
> > data structure, which could conceivably block.
>
> Is there some reason why the $target variable must be looked up each
> time it is accessed? Sounds slow.
It was the simplest functional expedient.
> I put the spinlock in at the last minute because I was worried that
> someone might be tempted to use it to try to resolve addresses
> during a kprobe. [...]
What would be the harm in that? IOW, what kind of concurrency problem
is the lock intended to prevent?
> [...] Moving the allocations into .data or .bss sections could
> still trigger OOM situations.
Yes, however, the difference is that even if the allocation size were
configurable by a user, it would be expressed in obvious units
(megabytes, rather than array rows).
> [...] I made this argument a year ago and was told to rewrite to
> allocate memory in small chunks with kmalloc. [...]
You will recall that, at the time, we were experiencing problems with
probing the proximity of the vmalloc fault handler path.
> Regarding OOM killer, shouldn't we just set oom_adj to something
> like +15? That would put us at the top of the victims list [...]
Who is that "us"? The staprun process? It's too late by then - the
module will not notice that staprun is gone until after the module's
allocation attempts have hurt the system.
- FChE