[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <48ADF3FC.7070002@keyaccess.nl>
Date: Fri, 22 Aug 2008 01:02:20 +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 21-08-08 19:15, Rene Herman wrote:
> On 21-08-08 14:06, Ingo Molnar wrote:
>> Would be nice to test tip/master - it has both that patch included and
>> the latest pageattr-array API (with enablement in AGP drivers)
>> patchset, done by Shaohua Li, based on Dave's original patch.
>
> That patch by itself doesn't help any -- the new set_memory_array_uc()
> still calls reserve_memtype() for each single page in the array. To
> help, it needs to coalesce adjacent entries, which is itself easy to do
> were it not for the need to keep the list of reserved (base,end) pairs
> around for free_memtype() time (and halfway fail time).
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?
NOTE: I am posting this because I'm going to bed but haven't stared
comfortably long at this and might be buggy. Compiles, boots and
provides me with:
root@...e4:~# wc -l /debug/x86/pat_memtype_list
53 /debug/x86/pat_memtype_list
otherwise (down from 16384+).
<snore>
Rene.
View attachment "0001-x86-have-set_memory_array_-uc-wb-coalesce-memtypes.patch" of type "text/plain" (2237 bytes)
Powered by blists - more mailing lists