lkml.org 
[lkml]   [2001]   [Dec]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] task_struct colouring ...
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/

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