All of lore.kernel.org
 help / color / mirror / Atom feed
From: "H. Peter Anvin" <hpa@zytor.com>
To: Andy Lutomirski <luto@amacapital.net>, Toshi Kani <toshi.kani@hp.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Arnd Bergmann <arnd@arndb.de>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	plagnioj@jcrosoft.com, tomi.valkeinen@ti.com,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Stefan Bader <stefan.bader@canonical.com>,
	Dave Airlie <airlied@gmail.com>, Borislav Petkov <bp@alien8.de>
Subject: Re: [RFC PATCH 3/11] x86, mm, pat: Change reserve_memtype() to handle WT type
Date: Tue, 15 Jul 2014 17:31:43 -0700	[thread overview]
Message-ID: <788fbcdc-4f69-4970-aaf4-00aae6c57fed@email.android.com> (raw)
In-Reply-To: <CALCETrXMYmVkcpzwGEo=aUia6S9aOaODFR__Z54YUQAZ4rRhRA@mail.gmail.com>

It already happened...

On July 15, 2014 5:28:40 PM PDT, Andy Lutomirski <luto@amacapital.net> wrote:
>On Tue, Jul 15, 2014 at 4:53 PM, Toshi Kani <toshi.kani@hp.com> wrote:
>> On Tue, 2014-07-15 at 16:36 -0700, Andy Lutomirski wrote:
>>> 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.
>>
>> Right.
>>
>> I think using struct page table for the RAM ranges is a good way for
>> saving memory, but I wonder how often the RAM ranges are mapped other
>> than WB...  If not often, reserve_memtype() could simply call
>> rbt_memtype_check_insert() for all ranges, including RAM.
>>
>> In this patch, I left using reserve_ram_pages_type() since I do not
>see
>> much reason to use WT for RAM, either.
>
>I hereby predict that someone, some day, will build a system with
>nonvolatile "RAM", and someone will want this feature.  Just saying :)
>
>More realistically, someone might want to write a silly driver that
>lets programs mmap some WT memory for testing.
>
>--Andy

-- 
Sent from my mobile phone.  Please pardon brevity and lack of formatting.

--
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>

WARNING: multiple messages have this Message-ID (diff)
From: "H. Peter Anvin" <hpa@zytor.com>
To: Andy Lutomirski <luto@amacapital.net>, Toshi Kani <toshi.kani@hp.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Arnd Bergmann <arnd@arndb.de>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	plagnioj@jcrosoft.com, tomi.valkeinen@ti.com,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Stefan Bader <stefan.bader@canonical.com>,
	Dave Airlie <airlied@gmail.com>, Borislav Petkov <bp@alien8.de>
Subject: Re: [RFC PATCH 3/11] x86, mm, pat: Change reserve_memtype() to handle WT type
Date: Tue, 15 Jul 2014 17:31:43 -0700	[thread overview]
Message-ID: <788fbcdc-4f69-4970-aaf4-00aae6c57fed@email.android.com> (raw)
In-Reply-To: <CALCETrXMYmVkcpzwGEo=aUia6S9aOaODFR__Z54YUQAZ4rRhRA@mail.gmail.com>

It already happened...

On July 15, 2014 5:28:40 PM PDT, Andy Lutomirski <luto@amacapital.net> wrote:
>On Tue, Jul 15, 2014 at 4:53 PM, Toshi Kani <toshi.kani@hp.com> wrote:
>> On Tue, 2014-07-15 at 16:36 -0700, Andy Lutomirski wrote:
>>> 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.
>>
>> Right.
>>
>> I think using struct page table for the RAM ranges is a good way for
>> saving memory, but I wonder how often the RAM ranges are mapped other
>> than WB...  If not often, reserve_memtype() could simply call
>> rbt_memtype_check_insert() for all ranges, including RAM.
>>
>> In this patch, I left using reserve_ram_pages_type() since I do not
>see
>> much reason to use WT for RAM, either.
>
>I hereby predict that someone, some day, will build a system with
>nonvolatile "RAM", and someone will want this feature.  Just saying :)
>
>More realistically, someone might want to write a silly driver that
>lets programs mmap some WT memory for testing.
>
>--Andy

-- 
Sent from my mobile phone.  Please pardon brevity and lack of formatting.

  reply	other threads:[~2014-07-16  0:32 UTC|newest]

Thread overview: 74+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-15 19:34 [RFC PATCH 0/11] Support Write-Through mapping on x86 Toshi Kani
2014-07-15 19:34 ` Toshi Kani
2014-07-15 19:34 ` [RFC PATCH 1/11] x86, mm, pat: Redefine _PAGE_CACHE_UC as UC_MINUS Toshi Kani
2014-07-15 19:34   ` Toshi Kani
2014-07-15 19:34 ` [RFC PATCH 2/11] x86, mm, pat: Define _PAGE_CACHE_WT for PA3/7 of PAT Toshi Kani
2014-07-15 19:34   ` Toshi Kani
2014-07-15 19:34 ` [RFC PATCH 3/11] x86, mm, pat: Change reserve_memtype() to handle WT type Toshi Kani
2014-07-15 19:34   ` Toshi Kani
2014-07-15 19:56   ` Andy Lutomirski
2014-07-15 19:56     ` Andy Lutomirski
2014-07-15 23:10     ` Toshi Kani
2014-07-15 23:10       ` Toshi Kani
2014-07-15 23:36       ` Andy Lutomirski
2014-07-15 23:36         ` Andy Lutomirski
2014-07-15 23:46         ` H. Peter Anvin
2014-07-15 23:46           ` H. Peter Anvin
2014-07-15 23:54           ` Andy Lutomirski
2014-07-15 23:54             ` Andy Lutomirski
2014-07-15 23:59             ` H. Peter Anvin
2014-07-15 23:59               ` H. Peter Anvin
2014-07-15 23:53         ` Toshi Kani
2014-07-15 23:53           ` Toshi Kani
2014-07-16  0:05           ` H. Peter Anvin
2014-07-16  0:05             ` H. Peter Anvin
2014-07-16  0:28           ` Andy Lutomirski
2014-07-16  0:28             ` Andy Lutomirski
2014-07-16  0:31             ` H. Peter Anvin [this message]
2014-07-16  0:31               ` H. Peter Anvin
2014-07-16 14:35             ` Toshi Kani
2014-07-16 14:35               ` Toshi Kani
2014-07-15 19:34 ` [RFC PATCH 4/11] x86, mm, asm-gen: Add ioremap_wt() for WT mapping Toshi Kani
2014-07-15 19:34   ` Toshi Kani
2014-07-15 19:34 ` [RFC PATCH 5/11] x86, mm: Add set_memory[_array]_wt() for setting WT Toshi Kani
2014-07-15 19:34   ` Toshi Kani
2014-07-15 19:34 ` [RFC PATCH 6/11] x86, mm, pat: Add pgprot_writethrough() for WT Toshi Kani
2014-07-15 19:34   ` Toshi Kani
2014-07-15 19:34 ` [RFC PATCH 7/11] x86, mm: Keep _set_memory_<type>() slot-independent Toshi Kani
2014-07-15 19:34   ` Toshi Kani
2014-07-15 19:34 ` [RFC PATCH 8/11] x86, mm, pat: Keep pgprot_<type>() slot-independent Toshi Kani
2014-07-15 19:34   ` Toshi Kani
2014-07-15 19:34 ` [RFC PATCH 9/11] x86, efi: Cleanup PCD bit manipulation in EFI Toshi Kani
2014-07-15 19:34   ` Toshi Kani
2014-07-15 19:34 ` [RFC PATCH 10/11] x86, xen: Cleanup PWT/PCD bit manipulation in Xen Toshi Kani
2014-07-15 19:34   ` Toshi Kani
2014-07-15 19:34 ` [RFC PATCH 11/11] x86, fbdev: Cleanup PWT/PCD bit manipulation in fbdev Toshi Kani
2014-07-15 19:34   ` Toshi Kani
2014-07-15 19:53 ` [RFC PATCH 0/11] Support Write-Through mapping on x86 Andy Lutomirski
2014-07-15 19:53   ` Andy Lutomirski
2014-07-15 20:10   ` H. Peter Anvin
2014-07-15 20:10     ` H. Peter Anvin
2014-07-15 20:09 ` H. Peter Anvin
2014-07-15 20:09   ` H. Peter Anvin
2014-07-15 21:23   ` Toshi Kani
2014-07-15 21:23     ` Toshi Kani
2014-07-16  0:40     ` Konrad Rzeszutek Wilk
2014-07-16  0:40       ` Konrad Rzeszutek Wilk
2014-07-16 21:28       ` Toshi Kani
2014-07-21 16:31         ` Toshi Kani
2014-07-21 16:47           ` H. Peter Anvin
2014-07-21 16:47             ` H. Peter Anvin
2014-07-21 17:16             ` Toshi Kani
2014-07-21 17:16               ` Toshi Kani
2014-07-21 17:32               ` H. Peter Anvin
2014-07-21 17:32                 ` H. Peter Anvin
2014-07-21 17:33                 ` Toshi Kani
2014-07-21 17:33                   ` Toshi Kani
2014-07-21 18:33                 ` Konrad Rzeszutek Wilk
2014-07-21 18:33                   ` Konrad Rzeszutek Wilk
2014-07-21 19:24                   ` Toshi Kani
2014-07-21 19:24                     ` Toshi Kani
2014-07-21 20:22                   ` H. Peter Anvin
2014-07-21 20:22                     ` H. Peter Anvin
2014-07-21 17:20             ` Toshi Kani
2014-07-21 17:20               ` Toshi Kani

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=788fbcdc-4f69-4970-aaf4-00aae6c57fed@email.android.com \
    --to=hpa@zytor.com \
    --cc=airlied@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=arnd@arndb.de \
    --cc=bp@alien8.de \
    --cc=konrad.wilk@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=luto@amacapital.net \
    --cc=mingo@redhat.com \
    --cc=plagnioj@jcrosoft.com \
    --cc=stefan.bader@canonical.com \
    --cc=tglx@linutronix.de \
    --cc=tomi.valkeinen@ti.com \
    --cc=toshi.kani@hp.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.