Messages in this thread | | | From | Andi Kleen <> | Subject | Re: [PATCH RFC 0/6] Implement per-processor data areas for i386. | Date | Sun, 27 Aug 2006 18:01:44 +0200 |
| |
Very cool.
> - Make it work. It works UP on a test QEMU machine, but it doesn't > yet work on real hardware, or SMP (though not working SMP on QEMU is > more likely to be a QEMU problem). Not sure what the problem is yet; > I'm hoping review will reveal something.
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?
Comparing with SimNow! (which should behave more like a real CPU) might be also interesting.
> - 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.
> - 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.
(weak point:)
- The stack protector code might work one day on i386 too.
-Andi - 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/
| |