And this all is a rather stupid testcase with no RL significance
IMO, designed to show alleged recalculation costs. Jonathan, WHERE
is that 'MAJOR bottleneck'?
Ok, then what I personally want is a firm quantification of where the
scheduling cost is coming from in the web server benchmarks.
I'm willing to accept any well founded explanation, and this is where
most of the concern has been coming from.
If it's galloping herd from some event queue, this should be painfully
easy to test for. My suggested scheme would be to have a "counter per
PC value" type array similar to what the normal kernel profiler uses,
but instead you record caller-PC values for entry into __wake_up().
Furthermore you could "scale" the counter bumps by adding, instead of
'1' for each __wake_up() call, the number of tasks woken during that
call.
The important thing to capture is "who is doing the wakeups" and "how
much waking up each time". You need to be slightly careful for some
of the networking stuff, because the true source of the wake up could
be 2 or 3 stack frame above the __wake_up() invocation.
Dump these values after a web benchmark run, and the answers should
just be there.
Any takers?
Later,
David S. Miller
davem@redhat.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/