linux-kernel - [PATCH] x86: have set_memory_array

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: <48AF1B6A.80408@keyaccess.nl>
Date:	Fri, 22 Aug 2008 22:02:50 +0200
From:	Rene Herman <rene.herman@...access.nl>
To:	Ingo Molnar <mingo@...e.hu>
CC:	Venki Pallipadi <venkatesh.pallipadi@...el.com>,
	Dave Airlie <airlied@...il.com>,
	"Li, Shaohua" <shaohua.li@...el.com>,
	Yinghai Lu <yhlu.kernel@...il.com>,
	Andreas Herrmann <andreas.herrmann3@....com>,
	Arjan van de Ven <arjan@...radead.org>,
	Linux Kernel <linux-kernel@...r.kernel.org>,
	"Siddha, Suresh B" <suresh.b.siddha@...el.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	"H. Peter Anvin" <hpa@...or.com>,
	Dave Jones <davej@...emonkey.org.uk>
Subject: [PATCH] x86: have set_memory_array_{uc,wb} coalesce memtypes.

On 22-08-08 06:15, Ingo Molnar wrote:

>> Actually, might as well simply reconstruct the memtype list at free 
>> time I guess. How is this for a coalescing version of the array 
>> functions?
> 
> impressive! Rarely do we get this much bang for such a low linecount :-)

Thanks. Stared at it a little longer now and there  was a small cut and 
paste error in the error path (s/start/tmp/) but other than that, yes, 
I'll stand by this. set_memory_array_{uc,wb}() set all pages to the same
type, so coalescing them makes sense in any usage case it seems.

The attached version fixes the out path, is otherwise identical and this 
time comes with a proper changelog and a sign-off. Given that you needed 
the changelog and the sign-off anyway, I thought there wouldn't be much 
point in doing that incrementally, but if you disagree and refactor -- a 
changelog for the out path fix would be a simple:

===
x86: fix "have set_memory_array_{uc,wb} coalesce memtypes".

Fix copy and paste error in out path

Signed-off-by: Rene Herman <rene.herman@...il.com>
===

> I'd do this in v2.6.27 but i forced myself to be reasonable and applied 
> your patches to tip/x86/pat instead, for tentative v2.6.28 merging 
> (assuming it all passes testing, etc.):

Yes, I agree not for .27

>  # 9a79f4f: x86: {reverve,free}_memtype() take a physical address
>  # c5e147c: x86: have set_memory_array_{uc,wb} coalesce memtypes.
>  # 5f310b6: agp: enable optimized agp_alloc_pages methods
> 
> ( note that i flipped them around a bit and have put your 
>   enable-agp_alloc_pages()-widely patch last, so that we get better 
>   bisection behavior. )
> 
> The frontside cache itself is in x86/urgent:
> 
>  # 80c5e73: x86: fix Xorg startup/shutdown slowdown with PAT
> 
> ... and should at least solve the symptom that you've hit in practice 
> (the slowdown), without changing the underlying PAT machinery. (which 
> would be way too dangerous for v2.6.27)

Well, please note that that specific commit only fixes X startup -- it 
doesn't do anything for shutdown. With only that one, I'm still at 14 
seconds for X shutdown (first time after boot that is, 5 seconds 
subsequent shutdowns) versus 1 (or sub 1, feels immediate) normally.

It's also a black-screen "hang", so we'll probably be getting a lot of 
"long hang at shutdown" reports without something additionally for .27.

Venki?

> And it's all merged up in tip/master, you might want to test that too to 
> check whether all the pieces fit together nicely.

Wasn't in tip/master when I just now fetched it. It does indeed sit in 
tip/x86/pat.

Rene.

View attachment "0001-x86-have-set_memory_array_-uc-wb-coalesce-memtypes.patch" of type "text/plain" (2923 bytes)