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
| ||
|
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/
Powered by blists - more mailing lists