[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <47F11ED3.40803@tungstengraphics.com>
Date: Mon, 31 Mar 2008 19:26:43 +0200
From: Thomas Hellström <thomas@...gstengraphics.com>
To: Arjan van de Ven <arjan@...ux.intel.com>
CC: Andi Kleen <andi@...stfloor.org>, Dave Airlie <airlied@...hat.com>,
linux-kernel@...r.kernel.org, tglx@...utronix.de, mingo@...hat.com
Subject: Re: [PATCH] x86: create array based interface to change page attribute
Arjan van de Ven wrote:
> Thomas Hellström wrote:
>> Arjan van de Ven wrote:
>>> Thomas Hellström wrote:
>>>
>>>> Let me rehprase. Not really time-critical but it is of some
>>>> importance that CPA is done quickly.
>>>> We're dealing with the tradeoff of reading from uncached device memory
>>>
>>> uncached or write combining ?
>> The user-space mappings (the ones that we really use) are usually
>> write-combined, whereas the kernel mappings are uncached. (I think
>> this is OK since both mapping types implies no cache coherency).
>
> This is not officially allowed and may tripple fault your cpu..
> To comply with the spec one needs to have ALL mappings the same
> unfortunately.
> (And yes, this is a hard problem)
>
Hmm...
Given this problem, the previously mentioned use-case, and the fact that
we mostly really use user-space mappings,
Is there a possibility we could add the following functions to Dave's
patch (provided they would work as intended, of course, namely
invalidate / bring back the kernel mapping).
Then we can set up a pool of unmapped pages, avoid frequent use of CPA
and everybody's happy.
int set_memory_array_np(unsigned long *addr, int addrinarray)
{
return change_page_attr_clr(addr, addrinarray,
__pgprot(_PAGE_PRESENT | _PAGE_RW), 1);
}
EXPORT_SYMBOL(set_memory_array_np);
int set_memory_array_p(unsigned long *addr, int addrinarray)
{
return change_page_attr_set(addr, addrinarray,
__pgprot(_PAGE_PRESENT | _PAGE_RW), 1);
}
EXPORT_SYMBOL(set_memory_array_p);
/Thomas
--
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