[lkml]   [2002]   [Oct]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Pathological case identified from contest
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.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:30    [W:0.046 / U:6.992 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site