Messages in this thread | | | Date | Mon, 10 Mar 2008 11:35:50 -0700 | From | Jeremy Fitzhardinge <> | Subject | Re: quicklists confuse meminfo |
| |
Andi Kleen wrote: >> 1. Xen marks the whole page as being of pgd-type, and so it can't >> have non-pgd contents (as the page would be RO, and any contents >> would be validated as pgd entries). However I can fix that by >> > > That sounds more like a Xen bug. Why should it validate anything except > the first four entries which are used by the hardware? > > I can imagine that false sharing would be slow because you would > have unnecessary traps, but it shouldn't be a correctness issue. >
Yeah, the most fundamental problem is that the whole page is RO, so even if Xen trapped and emulated, it still makes a very bad neighbour. I was also going to say that there's no reason why you couldn't pack multiple pgds into one page, but I think we can only specify the cr3 at page resolution anyway.
>> maintaining a separate per-cpu pgd page, and just copy the four >> entries over when cr3 is reloaded. This would move the >> Xen-specific requirements into the Xen code without affecting the >> rest of the kernel. >> > > x86-64 used to do that, but it turned out this breaks some shared cache > optimizations on the P4 between SMT threads. So you might actually see > user space performance regressions from it. >
Hm, given that Xen doesn't make any topology guarantees about vcpus, I don't think it would make much difference. I think it would only be observable if you actually pinned the vcpus to physical siblings. Besides we could easily maintain sibling info and look to see if we're about to reload cr3 to match the other thread(s), then just use the same pgd copy.
J
| |