Re: Pathological case identified from contest

[Andrew Morton <akpm@digeo.com>]

Con Kolivas wrote:
> 
> I found a pathological case in 2.5 while running contest with process_load
> recently after checking the results which showed a bad result for 2.5.43-mm1:
> 
> 2.5.43-mm1              101.38  72%     42      31%
> 2.5.43-mm1              102.90  75%     34      28%
> 2.5.43-mm1              504.12  14%     603     85%
> 2.5.43-mm1              96.73   77%     34      26%
> 
> This was very strange so I looked into it further
> 
> The default for process_load is this command:
> 
> process_load --processes $nproc --recordsize 8192 --injections 2
> 
> where $nproc=4*num_cpus
> 
> When I changed recordsize to 16384, many of the 2.5 kernels started exhibiting
> the same behaviour. While the machine was apparently still alive and would
> respond to my request to abort, the kernel compile would all but stop while
> process_load just continued without allowing anything to happen from kernel
> compilation for up to 5 minutes at a time. This doesnt happen with any 2.4 kernels.
> 

Well it doesn't happen on my test machine (UP or SMP).  I tried
various recordsizes.  It's probably related to HZ, memory bandwidth
and the precise timing at which things happen.

The test describes itself thusly:

 *  This test generates a load which simulates a process-loaded system.
 *
 *  The test creates a ring of processes, each connected to its predecessor
 *  and successor by a pipe.  After the ring is created, the parent process
 *  injects some dummy data records into the ring and then joins.  The
 *  processes pass the data records around the ring until they are killed.
 *

It'll be starvation in the CPU scheduler I expect.  For some reason
the ring of piping processes is just never giving a timeslice to
anything else.  Or maybe something to do with the exceptional
wakeup strategy which pipes use.

Don't now, sorry.  One for the kernel/*.c guys.