lkml.org 
[lkml]   [2001]   [Jan]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [Lse-tech] more on scheduler benchmarks
From
Date

Hubertus wrote :

> The only problem I have with sched_yield like benchmarks is that it
creates
> artificial lock contention as we basically spent most of the time other
> then context switching + syscall under the scheduler lock. This we won't
> see in real apps, that's why I think the chatroom numbers are probably
> better indicators.

Agreed. 100% artificial. The intention of the benchmark is to put a lot
of pressure on the scheduler so that the benchmark results will be very
"sensitive" to changes in schedule(). For example, if you were to split
the scheduling fields used by goodness() into several cache lines, the
benchmark results should reveal the degradation. chatroom would probably
show it too though. At some point, we could run your patch on our
SPECweb99 setup using Zeus - we don't have any lock analysis data on the
workload yet so I don't know what the contention on the run_queue lock is.
Zeus does not use many threads. Apache does.

Bill

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

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