linux-kernel - Re: quicklists confuse meminfo

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 10 Mar 2008 11:35:50 -0700
From:	Jeremy Fitzhardinge <jeremy@...p.org>
To:	Andi Kleen <andi@...stfloor.org>
CC:	Hugh Dickins <hugh@...itas.com>,
	Christoph Lameter <clameter@....com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Ingo Molnar <mingo@...e.hu>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	LKML <linux-kernel@...r.kernel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Bart Van Assche <bart.vanassche@...il.com>
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/