Re: sched_test_yield benchmark

Davide Libenzi (davidel@xmail.virusscreen.com)
Fri, 19 Jan 2001 08:35:55 -0800


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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/