On Thu, Jul 16, 2015 at 12:27 PM, Andy Lutomirski [off-list ref] wrote:
If we actually bit the bullet and implemented per-cpu mappings
That's not ever going to happen.
Per-cpu page tables are a complete disaster. It's a recipe for crazy
race conditions, when you have CPUs that update things like
dirty/accessed bits atomically etc, and you have fundamental races
when multiple CPU's allocating page tables at the same time (remember:
we have concurrent page faults, and the locking is not per-vm, it's at
a finer granularity).
It's also a big memory management problem when you have lots and lots of CPU's.
So don't go there. The only way to do per-cpu virtual mappings is
hardware-specific, it if you have hardware that explicitly allows
inserting percpu TLB entries (while still sharing the page tables),
then that would be ok. And we don't have that on x86. MIPS has
explicit support for these kinds of TLB backs, and obviously on other
architectures you might be able to play games with the SW-fill TLB,
but on x86 there's no hardware support for per-CPU TLB filling.
And this is not just theory. We've seen what happens when people try
to do per-thread page tables. It's happened several times, and it's a
fundamental mistake. Plan-9 had "private mappings" because that's how
they did stacks (ie the stack mappings were thread-local), and it
means that thread switching is fundamentally broken. I think Mach did
too. And per-cpu page tables are less broken from a scheduling
standpoint than per-thread page tables, but still do share a lot of
the synchronization problems, and have some allocation issues all
their own.
The Linux VM model of "one page table per VM" is the right one.
Anything else sucks, and makes threading a disaster.
So you can try to prove me wrong, but seriously, I doubt you'll succeed.
On x86, if you want per-cpu memory areas, you should basically plan on
using segment registers instead (although other odd state has been
used - there's been the people who use segment limits etc rather than
the *pointer* itself, preferring to use "lsl" to get percpu data. You
could also imaging hiding things in the vector state somewhere if you
control your environment well enough).
Linus
On Fri, Jul 17, 2015 at 11:48:14AM -0700, Linus Torvalds wrote:
On Thu, Jul 16, 2015 at 12:27 PM, Andy Lutomirski [off-list ref] wrote:
quoted
If we actually bit the bullet and implemented per-cpu mappings
That's not ever going to happen.
The Linux VM model of "one page table per VM" is the right one.
Anything else sucks, and makes threading a disaster.
So you can try to prove me wrong, but seriously, I doubt you'll succeed.
On x86, if you want per-cpu memory areas, you should basically plan on
using segment registers instead (although other odd state has been
used - there's been the people who use segment limits etc rather than
the *pointer* itself, preferring to use "lsl" to get percpu data. You
could also imaging hiding things in the vector state somewhere if you
control your environment well enough).
Thats correct, problem is that you need some sort of hack like this on
archs that otherwise would need syscall to get tid/access tls variable.
On x64 and archs that have register for tls this could be implemented
relatively easily.
Kernel needs to allocate
int running_cpu_for_tid[32768];
On context switch it atomically writes to this table
running_cpu_for_tid[tid] = cpu;
This table is read-only accessible from userspace as mmaped file.
Then userspace just needs to access it with three indirections like:
__thread tid;
char caches[CPU_MAX];
#define getcpu_cache caches[tid > 32768 ? get_cpu() : running_cpu_for_tid[tid]]
With more complicated kernel interface you could eliminate one
indirection as we would use void * array instead and thread could do
syscall to register what values it should use for each thread.
From: Andy Lutomirski <hidden> Date: 2015-07-17 23:33:42
On Fri, Jul 17, 2015 at 4:28 PM, Ondřej Bílka [off-list ref] wrote:
On Fri, Jul 17, 2015 at 11:48:14AM -0700, Linus Torvalds wrote:
quoted
On x86, if you want per-cpu memory areas, you should basically plan on
using segment registers instead (although other odd state has been
used - there's been the people who use segment limits etc rather than
the *pointer* itself, preferring to use "lsl" to get percpu data. You
could also imaging hiding things in the vector state somewhere if you
control your environment well enough).
Thats correct, problem is that you need some sort of hack like this on
archs that otherwise would need syscall to get tid/access tls variable.
On x64 and archs that have register for tls this could be implemented
relatively easily.
Kernel needs to allocate
int running_cpu_for_tid[32768];
On context switch it atomically writes to this table
running_cpu_for_tid[tid] = cpu;
This table is read-only accessible from userspace as mmaped file.
Then userspace just needs to access it with three indirections like:
__thread tid;
char caches[CPU_MAX];
#define getcpu_cache caches[tid > 32768 ? get_cpu() : running_cpu_for_tid[tid]]
With more complicated kernel interface you could eliminate one
indirection as we would use void * array instead and thread could do
syscall to register what values it should use for each thread.
Or we implement per-cpu segment registers so you can point gs directly
at percpu data. This is conceptually easy and has no weird ABI
issues. All it needs is an implementation and some good tests.
I think the API should be "set gsbase to x + y*(cpu number)". On
x86_64, userspace just allocates a big swath of virtual space and
populates it as needed.
--Andy
On Sat, Jul 18, 2015 at 01:28:36AM +0200, Ondřej Bílka wrote:
On Fri, Jul 17, 2015 at 11:48:14AM -0700, Linus Torvalds wrote:
quoted
On Thu, Jul 16, 2015 at 12:27 PM, Andy Lutomirski [off-list ref] wrote:
quoted
If we actually bit the bullet and implemented per-cpu mappings
That's not ever going to happen.
The Linux VM model of "one page table per VM" is the right one.
Anything else sucks, and makes threading a disaster.
So you can try to prove me wrong, but seriously, I doubt you'll succeed.
On x86, if you want per-cpu memory areas, you should basically plan on
using segment registers instead (although other odd state has been
used - there's been the people who use segment limits etc rather than
the *pointer* itself, preferring to use "lsl" to get percpu data. You
could also imaging hiding things in the vector state somewhere if you
control your environment well enough).
Thats correct, problem is that you need some sort of hack like this on
archs that otherwise would need syscall to get tid/access tls variable.
On x64 and archs that have register for tls this could be implemented
relatively easily.
Kernel needs to allocate
int running_cpu_for_tid[32768];
This does not scale. You're assuming the default task ("pid") number
limit, but this can be raised up to 512k (beyond that is impossible
because of PI/robust futex ABI).
On context switch it atomically writes to this table
running_cpu_for_tid[tid] = cpu;
This table is read-only accessible from userspace as mmaped file.
There is a much simpler solution: use a per-cpu (rather than per-task)
page that contains the right value for the cpu. I believe vdso already
does something like this, no?
Rich
On Fri, Jul 17, 2015 at 04:33:42PM -0700, Andy Lutomirski wrote:
On Fri, Jul 17, 2015 at 4:28 PM, Ondřej Bílka [off-list ref] wrote:
quoted
On Fri, Jul 17, 2015 at 11:48:14AM -0700, Linus Torvalds wrote:
quoted
On x86, if you want per-cpu memory areas, you should basically plan on
using segment registers instead (although other odd state has been
used - there's been the people who use segment limits etc rather than
the *pointer* itself, preferring to use "lsl" to get percpu data. You
could also imaging hiding things in the vector state somewhere if you
control your environment well enough).
Thats correct, problem is that you need some sort of hack like this on
archs that otherwise would need syscall to get tid/access tls variable.
On x64 and archs that have register for tls this could be implemented
relatively easily.
Kernel needs to allocate
int running_cpu_for_tid[32768];
On context switch it atomically writes to this table
running_cpu_for_tid[tid] = cpu;
This table is read-only accessible from userspace as mmaped file.
Then userspace just needs to access it with three indirections like:
__thread tid;
char caches[CPU_MAX];
#define getcpu_cache caches[tid > 32768 ? get_cpu() : running_cpu_for_tid[tid]]
With more complicated kernel interface you could eliminate one
indirection as we would use void * array instead and thread could do
syscall to register what values it should use for each thread.
Or we implement per-cpu segment registers so you can point gs directly
at percpu data. This is conceptually easy and has no weird ABI
issues. All it needs is an implementation and some good tests.
That only works if you have free register on your arch. As gs there was
rfc to teach gcc use it which could give bigger speedup. I didn't see
how much this could help yet so I am bit skeptical.
I think the API should be "set gsbase to x + y*(cpu number)". On
x86_64, userspace just allocates a big swath of virtual space and
populates it as needed.
That wouldn't work well if two shared libraries want to use that. You
would need to use something like se it to 4096*cpu_number or so.
Also we didn't considered yet overhead, as this slows down everything a
bit due slower context switches. So will this needs to have widespread
performance improvement to be worthwhile. What are use cases to make
that pay itself?