On Sun, Dec 09, 2001 at 05:38:42PM -0800, Davide Libenzi wrote:
> Coming at the pipe example, let's take Larry's lat_ctx ( lmbench ).
> This is bouncing data through pipes using I/O bound tasks, and running
> vmstat together with a lat_ctx 32 32 ... ( long list ), you'll see the run
> queue length barley reach 3 ( with 32 bouncing tasks ).
> It barely reaches 5 with 64 bouncing tasks.
This may show my ignorance, but ... Why would one expect much
more than 2 runnable tasks as a result of a running lat_ctx?
This benchmark simply passes a token around a ring of tasks.
One task awakens the next, then goes to sleep. The only time
you have more than one runnable task is during the times when
the token is passed between tasks. In these transition times
I would rarely expect more than 2 tasks on the runqueue no
matter how many bouncing tasks you have.
We created a benchmark similar to lat_ctx that would allow you
to control how many runnable tasks there are in the system.
Look for 'Reflex' benchmark at:
You can think of this as a controlled way of running multiple
copies of lat_ctx in parallel.
-- Mike - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to email@example.com More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Dec 15 2001 - 21:00:19 EST