Re: [RFC PATCH 3/11] x86, mm, pat: Change reserve_memtype() to handle WT type

[Andy Lutomirski <luto@amacapital.net>]

On Tue, Jul 15, 2014 at 4:10 PM, Toshi Kani <toshi.kani@hp.com> wrote:
> On Tue, 2014-07-15 at 12:56 -0700, Andy Lutomirski wrote:
>> On Tue, Jul 15, 2014 at 12:34 PM, Toshi Kani <toshi.kani@hp.com> wrote:
>> > This patch changes reserve_memtype() to handle the new WT type.
>> > When (!pat_enabled && new_type), it continues to set either WB
>> > or UC- to *new_type.  When pat_enabled, it can reserve a given
>> > non-RAM range for WT.  At this point, it may not reserve a RAM
>> > range for WT since reserve_ram_pages_type() uses the page flags
>> > limited to three memory types, WB, WC and UC.
>>
>> FWIW, last time I looked at this, it seemed like all the fancy
>> reserve_ram_pages stuff was unnecessary: shouldn't the RAM type be
>> easy to track in the direct map page tables?
>
> Are you referring the direct map page tables as the kernel page
> directory tables (pgd/pud/..)?
>
> I think it needs to be able to keep track of the memory type per a
> physical memory range, not per a translation, in order to prevent
> aliasing of the memory type.

Actual RAM (the lowmem kind, which is all of it on x86_64) is mapped
linearly somewhere in kernel address space.  The pagetables for that
mapping could be used as the canonical source of the memory type for
the ram range in question.

This only works for lowmem, so maybe it's not a good idea to rely on it.

--Andy

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>