I think we want to avoid it even in 2.3.x - not only are there
potentially DMA-able areas in stack space (I know the driver I'm working
on - USB - has that behaviour), but I'd rather avoid having the TLB
impact of a mapped stack. On many architectures (including the x86 due
to the 4M pages), it is cheaper to have a 1:1 mapping than to have
normal page mappings.
> vmalloc I seem to remember already
>does guard pages
Yup.
>> 2) if a task is created, then 2 single pages get allocated,
>> and inserted into the vm_alloc'ed area.
>> 3) the task_struct is moved to the end of the stack.
>> (Windows 95 does it this way around)
>
>The task struct is where it is in order to make dereferencing current
>fast.
It's not much worse to move it to the end: you do it with something like
this:
get_current()
{
movl $0x1ffc,%edx
orl %esp,%edx
return %edx-(sizeof(struct task_struct)-4);
}
and then the compiler most of the time can use a negative memory offset
to essentially create the same code as we have now. The one real
downside is that instead of having a small positive offset you have a
larger negative one, which tends to take up more space. We could work
around that by putting the commonly used stuff at the end of the struct
task_struct, but I'm not sure it is worth it.
I considered doing it this way originally, I think I went with the
low-mem struct task_struct mainly because it was more obvious, and
because it can be cheaper. A high-mem struct task_struct has its own
advantages, though, so it's by no means a clear choice either way.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/