linux-kernel - Re: [PATCh] x86: overmapped fix when 4K pages on tail

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]

Message-ID: <487A6AD0.5000506@firstfloor.org>
Date:	Sun, 13 Jul 2008 22:51:28 +0200
From:	Andi Kleen <andi@...stfloor.org>
To:	Ingo Molnar <mingo@...e.hu>
CC:	Yinghai Lu <yhlu.kernel@...il.com>,
	Arjan van de Ven <arjan@...radead.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	"H. Peter Anvin" <hpa@...or.com>,
	Suresh Siddha <suresh.b.siddha@...el.com>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCh] x86: overmapped fix when 4K pages on tail - 64bit

Ingo Molnar wrote:
> * Andi Kleen <andi@...stfloor.org> wrote:
> 
>>> with this patch, my 256g system still use gbpages for 1g-3g, 4g-256g
>> 256GB certainly qualifies as "large system". But as Linus always says: 
>> Linux is not for servers only. Ignoring the small systems makes you 
>> look bad.
> 
> Yinghai is hard at work fixing long-time crappiness of the x86 memory 
> setup code on 32-bit and 64-bit x86 alike. Contrary to your suggestion 
> he has not been "ignoring small systems" in any way - he has done the 
> exact opposite: Yinghai has fixed a ton of small-system bugs and 
> usability annoyances along the way.

I haven't read them all so I have no real opinion on those.

As a general comment I must admit I am a little uneasy with extensive
changes in early boot up because this code is hard to test completely
and fragile (that is why I was always conservative in this area).

But we'll see how it fares and it's your decision anyways
(but of course people will also blame you, not me, if it goes wrong ;-)

> Your attempt trying to cast this much-needed cleanup, fixing and 
> robustization effort into a negative light is as pityful as it is wrong.

First I was only commenting on one specific patch, nothing more.

My point is full rounding to 4K on all corners is wasteful because the
CPUs have to handle that case anyways and every split costs precious
TLB entries in direct mapping accesses.

And on small systems this hurts more because a much larger fraction
of their mapped memory will be affected by this. Yes on a large system like his
256GB box it's more a rounding error (although one that can also cause
weird performance hickups there when suddenly some kernel internal
operation that happens to hit the wrong memory takes much longer).

And I might be old fashioned, but I still think minimizing TLB misses
in the kernel is still quite important since the TLBs of modern x86
CPUs are still comparatively small.

btw that is why I was  also quite disappointed that the new cpa eliminated
reassembly. It means that on a long uptime system even with moderate
traffic of CPA page allocation/free eventually the completely direct mapping
will be all 4K. And there will be TLB miss galore on each system call
when user space is TLB intensive.

Ok in that light Yinghai's patch is perhaps not so bad after longer
uptime in that scenario. Still performance directly after boot up is
also something that shouldn't be ignored and I'm still hopefully that
reassembly will be readded at some point anyways.

-Andi

--
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/