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/