On Fri, 2006-09-22 at 15:24 -0700, Jeremy Fitzhardinge wrote: > Rusty Russell wrote: > > This patch implements save/restore of %gs in the kernel, so it can be > > used for per-cpu data. This is not cheap, and we do it for UP as well > > as SMP, which is stupid. Benchmarks, anyone? > > > I measured the cost as adding 9 cycles to a null syscall on my Core Duo > machine. I have not explicitly measured it on other machines, but I run > a number of other segment save/load tests on a wide range of machines, > and didn't find much variability. Oh, OK! I had a belief that segment loading was expensive, perhaps I'm off-base here. > I think saving/restoring %gs will still be necessary. There are a number > of places in the kernel which expect to find the usermode %gs on the > kernel stack frame, including context switch, ptrace, vm86, signal > context, and maybe something else. If you don't save it on the stack, > then you need to have UP variations of %gs handling in all those other > places, which is pretty messy. Also, unless you want to have two > definitions of struct_pt regs (which would add even more mess into > ptrace), you'd still need to sub/add %esp in entry.S to skip over the > %gs hole. I don't think this UP microoptimisation would be worth enough > to justify the mess it would cause elsewhere. > > How does this version of the patch differ from mine? Is it just my > patch+Ingo's fix, or are there other changes? I couldn't see anything > from a quick read-over. Yep, no substative changes. s/__KERNEL_PDA/__KERNEL_PERCPU/, plus your version had a "write_pda(pcurrent, next_p)" inserted in process.c's __switch_to which belonged in a successor patch... Thanks! Rusty. -- Help! Save Australia from the worst of the DMCA: http://linux.org.au/law
