Re: [PATCH] task_struct colouring ...

[Davide Libenzi]

On Sat, 1 Dec 2001, Manfred Spraul wrote:

> >
> > 2) Code clarity
> >
> I really liked Ben's idea of an include file with macros for asm access to the current pointer.
> That was a major improvement for the code clarity. IMHO a patch that changes current
> should introduce such a file.
>
> >       unsigned long tskb = __get_free_pages(GFP_KERNEL, 1), tsk;
> >      tsk = tskb | ((tskb >> 13) & 0x00000060) | SMP_CACHE_BYTES;
> >      *(unsigned long *) tskb = tsk;
>
> You only colour 2 bits (offset 32, 64 or 96 - all within one cacheline on P 4) - I doubt that this
> helps a lot. And you do not colour the stack top - all processes sleeping in accept() will still
> have their wait queues at the same cache colour. And if you use more bits, you risk
> stack overflows.

32, 64, 96 and 128
Anyway it's clear that this is a 32 cache line size setup and that such
magic numbers have to change accounding to cache line size and
associativity level.
True that with CPUs with 7 or more bits for cache line size we're going to
be subject of stack overflow.
More then increasing stack allocation i'd rather prefer to allocate two
items ( like your patch ) 1) the task_struct from a slab 2) the stack with
__get_free_pages().
What I do not really like is storing pointers inside global CPU registers,
at least until the perf difference will justify it ( we'll see ).
The stack jittering is quite easy to implement in arch/??/kernel/process.c
and another couple of fixes.
I'll try slab task struct allocation + stack base pointer indirection.

- Davide