current as segment register was Re: Using %cr2 to reference "current"

current as segment register was Re: Using %cr2 to reference "current"

[Andi Kleen]

Linus Torvalds <torvalds@transmeta.com> writes:


> There are some people who think that the 5kB stack we have now is too
> small ;(

It was too small on x86-64 ;)

> 
> So it would basically be a small per-CPU/thread area, not just the "struct
> task_struct".

x86-64 has such a per cpu area. It is accessed via gs. It is needed to make
the SYSCALL system entry code work. So far I didn't move
that many fields into it to keep the patches small, but current is just
a field in the PDA (processor data area). The x86-64 has special instructions
to quickly save/restore gs on kernel entry.

One nasty thing is that lea doesn't work on segment registers. It needs
an quite ugly inline assembly mess similar to get/put_user to implement
read/write/add_pda functions for the fundamental types. To implement
that properly without hardcoded offsets it is also needed to have an
offset.c like many other ports that puts structure offsets at compile
time into an include file.

Also all system entry have to enter with interrupts off to avoid races
in switching %gs.

So far I have not moved the task_struct into a slab cache yet, but it is
a trivial step now because all the infrastructure is there.

The code size impact seems to be minimal between current as rsp & mask and 
%gs:current_offset.  smp_processor_id() is much cheaper however. The current
x86 implementation of that was quite bad.

Long term I hope more per CPU data (e.g. in networking, in the scheduler or 
in interrupt handling) should migrate into the per data area.
Accessing the data there is much more efficent than indexing an cache line
padded array, and it saves a lot of cache too because the cache lines can be 
shared.

-Andi

Re: current as segment register was Re: Using %cr2 to reference "current"

[Keith Owens]

On 06 Nov 2001 20:02:09 +0100, 
Andi Kleen <ak@suse.de> wrote:
>One nasty thing is that lea doesn't work on segment registers. It needs
>an quite ugly inline assembly mess similar to get/put_user to implement
>read/write/add_pda functions for the fundamental types. To implement
>that properly without hardcoded offsets it is also needed to have an
>offset.c like many other ports that puts structure offsets at compile
>time into an include file.

Already done in kbuild 2.5, it creates arch/i386/asm-offsets.h.
Currently containing this list, which can easily be expanded.

#ifndef __ASM_OFFSETS_H__
#define __ASM_OFFSETS_H__
/*
 * DO NOT MODIFY
 *
 * This file was generated by arch/i386/Makefile.in.
 *
 */

state                =   0                      /* 0x0     offsetof(struct task_struct, state) */
flags                =   4                      /* 0x4     offsetof(struct task_struct, flags) */
sigpending           =   8                      /* 0x8     offsetof(struct task_struct, sigpending) */
addr_limit           =  12                      /* 0xc     offsetof(struct task_struct, addr_limit) */
exec_domain          =  16                      /* 0x10    offsetof(struct task_struct, exec_domain) */
need_resched         =  20                      /* 0x14    offsetof(struct task_struct, need_resched) */
tsk_ptrace           =  24                      /* 0x18    offsetof(struct task_struct, ptrace) */
processor            =  52                      /* 0x34    offsetof(struct task_struct, processor) */

ENOSYS               =  38                      /* 0x26    ENOSYS */

#endif