Messages in this thread |  | | Date | Sat, 1 Dec 2001 16:11:08 -0800 (PST) | From | Davide Libenzi <> | Subject | Re: [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/
|  |