Re: offline elfutils processing committed

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

hunt wrote:

> [...]
> > What would be the harm in that?  IOW, what kind of concurrency problem
> > is the lock intended to prevent?
> 
> Module loads (and eventually unloads) will update the list of modules
> and their symbols. This cannot happen while a kprobe is looking through
> the list resolving some symbol.

OTOH if a module load is in progress, kprobes would be locked out.
Have you characterized how long such a duration could be?  (At last
it's mostly moot once the relocation call is taken out of its current
homestead in the $variable fetcher functions.)

> > > 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 [...]
> Yeah, "us" means staprun and the systemtap module.
> 
> The point is damage control.  Systemtap allocates too much memory and
> oom killer gets active, the first thing it will kill is staprun and that
> should unload the module [...]

But it's too late by then.  Most or all the memory allocation attempts
take place in one big lump during one short interval, between checks
for the continued existence of the staprun process.  So if the
attempts are too aggressive, sure staprun will be zapped, but so will
many other programs, by the time the probe module would notice.

- FChE