lkml.org 
[lkml]   [2008]   [Mar]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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


\
 
 \ /
  Last update: 2008-03-10 19:39    [W:0.715 / U:0.100 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site