[lkml]   [2001]   [Jan]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: sched_test_yield benchmark
On Friday 19 January 2001 07:59, Bill Hartner wrote:
> Just a couple of notes on the sched_test_yield benchmark.
> I posted it to the mailing list in Dec. I have a todo to get
> a home for it. There are some issues though. See below.
> (1) Beware of the changes in sys_sched_yield() for 2.4.0. Depending
> on how many processors on the test system and how many threads
> created, schedule() may or may not be called when calling
> sched_yield().

In Your test You're using at least 16 tasks with an 8 way SMP, so schedule()
should be always called ( if You're using my test suite tasks are always
running ).

> (3) For the i386 arch :
> My observations were made on an 8-way 550 Mhz PIII Xeon 2MB L2 cache.

Hey, this should be the machine I've lost two days ago :^)

> The task structures are page aligned. So when running the benchmark
> you may see what I *suspect* are L1/L2 cache effects. The set of
> yielding threads will read the same page offsets in the task struct
> and will dirty the same page offsets on it's kernel stack. So
> depending on the number of threads and the locations of their task
> structs in physical memory and the associatively of the caches, you
> may see (for example) results like :
> ** ** **
> 50 50 50 50 75 50 50 35 50 50 50 50 75
> Also, the number of threads, the order of the task structs on the
> run_queue, thread migration from cpu to cpu, and how many times
> recalculate is done may vary the results from run to run.

Yep, this is the issue.
Why not move scheduling fields in a separate structure with a different
alignment :

struct s_sched_fields {
} sched_fields[];

inline struct s_sched_fields * get_sched_fields_ptr(task_struct * ) {


This will reduce the probability that scheduling fields will fall onto the
same cache line.

- Davide
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

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