Re: context allocation failure

["Frank Ch. Eigler" <fche at elastic dot org>]

Hi -

kevinrs wrote:

> I get this error when running the following command with the latest 
> build of SystemTap:
> 
> [root@home ]# stap -ve 'probe kernel.syscall.access {}'
> ERROR: percpu context (size 154348) allocation failed

Actually, I bet it's not the latest - I committed one improvement this
evening that should reduce that amount by about a third, and sneak
under the 128K limit.

> [...]  The problem is that reference to a single helper function
> will translate the entire contents of the file in which it is
> contained. [...]

That's not precisely the reason.  Because of the use of *union*,
context size depends on the *maximum* of the per-function and
per-probe locals/temporaries, not on their *total*.  So, even one
"large" function is enough for the context to get oversize.  And one
such function happens to be sitting within the aux_syscalls.stp file.
Having any number of "smaller" functions be pulled into the
translation session would not cause any growth to the context array.

> [root@home ]# stap -DMAXNESTING=10 -e 'probe kernel.syscall.access {}'

Just to spell it out, this works because the total context size is
multiplicatively affected by the number of function nesting levels.

> Before today, I never encountered this behavior. I suspect that it
> is one of the most recent CVS commits that generates the error.

The context allocation was initially revamped due to bug #1917 a few
days ago, which was also listed in the ChangeLog.  I believe using
kmalloc() is safer, in light of the vmalloc() faulting problems
reported last week.  This imposes tighter limits, but I think we can
live within them.  The translator can do a much better job than it is
doing now, by allocating a tighter context, computing an actual
MAXNESTING value that reflects actual script, and by other means.

- FChE