From: Andi Kleen <ak@suse.de>
To: Linus Torvalds <torvalds@transmeta.com>
Cc: linux-kernel@vger.kernel.org
Subject: current as segment register was Re: Using %cr2 to reference "current"
Date: 06 Nov 2001 20:02:09 +0100 [thread overview]
Message-ID: <p73lmhjyb7y.fsf_-_@amdsim2.suse.de> (raw)
In-Reply-To: <E161AkQ-0001Fp-00@the-village.bc.nu.suse.lists.linux.kernel> <Pine.LNX.4.33.0111061006150.2222-100000@penguin.transmeta.com.suse.lists.linux.kernel>
In-Reply-To: Linus Torvalds's message of "6 Nov 2001 19:20:45 +0100"
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
next parent reply other threads:[~2001-11-06 19:02 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <E161AkQ-0001Fp-00@the-village.bc.nu.suse.lists.linux.kernel>
[not found] ` <Pine.LNX.4.33.0111061006150.2222-100000@penguin.transmeta.com.suse.lists.linux.kernel>
2001-11-06 19:02 ` Andi Kleen [this message]
2001-11-07 3:42 ` Keith Owens
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=p73lmhjyb7y.fsf_-_@amdsim2.suse.de \
--to=ak@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@transmeta.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®