Messages in this thread | | | Date | Sun, 27 Aug 2006 09:41:17 -0700 | From | Jeremy Fitzhardinge <> | Subject | Re: [PATCH RFC 0/6] Implement per-processor data areas for i386. |
| |
Andi Kleen wrote: > I bet qemu doesn't have a real descriptor cache unlike real CPUs. > So likely it is some disconnect between changing the backing GDT > and referencing the register. Reload %gs more aggressively? >
The GDT only gets touched once in cpu_init(), and %gs is reloaded on every kernel entry, so I don't think that's it. I seems to have interrupt issues with SMP.
And either way, it still doesn't work on real hardware...
> Comparing with SimNow! (which should behave more like a real CPU) > might be also interesting. >
Yeah, I'll have to try that out.
>> - Measure performance impact. The patch adds a segment register >> save/restore on entry/exit to the kernel. This expense should be >> offset by savings in using the PDA while in the kernel, but I haven't >> measured this yet. Space savings are already appealing though. >> - Modify more things to use the PDA. The more that uses it, the more >> the cost of the %gs save/restore is amortized. smp_processor_id and >> current are the obvious first choices, which are implemented in this >> series. >> > > per cpu data would be the prime candidate. It is pretty simple. >
Well, it has to be arch-specific per-cpu data, since the PDA is arch specific. But there should be various pieces of interrupt state that adapt well to it.
>> - Make it a config option? UP systems don't need to do any of this, >> other than having a single pre-allocated PDA. Unfortunately, it gets >> a bit messy to do this given the changes needed in handling %gs. >> > > Please don't. >
Yeah, that wasn't really a serious thought...
J - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |