Re: [PATCH] task_struct colouring ...

From: Davide Libenzi (davidel@xmailserver.org)
Date: Sat Dec 01 2001 - 19:11:08 EST


On Sun, 2 Dec 2001 kumon@flab.fujitsu.co.jp wrote:

> Davide Libenzi writes:
> > On Sat, 1 Dec 2001, Alan Cox wrote:
> > > Because it is much much much faster
> >
> > We'll see how much faster is the global register allocation against code
> > like :
> >
> > movl %esp, %eax
> > andl $-8192, %eax
> > movl (%eax), %eax
>
> Current should be much faster, if it is accessed very frequently.
> If the frequency is high, the value is very likely being kept on L1
> cache. If that's true, the access time is fast enough.
> So, using indirection doesn't cause large penalty.
>
> Apart from that, stack coloring is difficult. Recent CPUs use much
> larger cache block, coloring needs big room in the stack area.
> Pentium4 is said using 64B block, but actually it is sectored cache
> within 128B block.
> 1KB room for stack coloring realizes only 8 colors.

true, that's why I'm using the Manfred idea of a separate allocation of
task structs through a slab allocator ( with task struct pointer stored at
stack base ) + init stack pointer jittering.
true even that with 128 bytes you'll get 8 colors in 1Kb, but 8 colors are
about 1/8 collision.

- Davide

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



This archive was generated by hypermail 2b29 : Fri Dec 07 2001 - 21:00:17 EST