All of lore.kernel.org
 help / color / mirror / Atom feed
From: "H. Peter Anvin" <hpa@zytor.com>
To: Andy Lutomirski <luto@amacapital.net>
Cc: Toshi Kani <toshi.kani@hp.com>,
	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 16:59:34 -0700	[thread overview]
Message-ID: <53C5C066.2060707@zytor.com> (raw)
In-Reply-To: <CALCETrUV2NseM8u6YqQ3trqLy+10_A6sd7nmfkgO3Rnw3GSxiQ@mail.gmail.com>

On 07/15/2014 04:54 PM, Andy Lutomirski wrote:
> 
> From vague memory, the current mechanism for tracking RAM memtypes (as
> opposed to memtypes for everything that isn't RAM) is limited to a
> very small number of types, leading to oddities like not being able to
> create WT ram with this patchset.
> 
> Using the pagetables directly would be simpler (no extra data
> structure) and would automatically exactly track the set of memtypes
> that can fit in the pagetable structures.
> 

I don't think there is anything fundamental, though.  The number of
types had more to do with what there was demand for.  I will look into it.

	-hpa


--
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>
Cc: Toshi Kani <toshi.kani@hp.com>,
	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 16:59:34 -0700	[thread overview]
Message-ID: <53C5C066.2060707@zytor.com> (raw)
In-Reply-To: <CALCETrUV2NseM8u6YqQ3trqLy+10_A6sd7nmfkgO3Rnw3GSxiQ@mail.gmail.com>

On 07/15/2014 04:54 PM, Andy Lutomirski wrote:
> 
> From vague memory, the current mechanism for tracking RAM memtypes (as
> opposed to memtypes for everything that isn't RAM) is limited to a
> very small number of types, leading to oddities like not being able to
> create WT ram with this patchset.
> 
> Using the pagetables directly would be simpler (no extra data
> structure) and would automatically exactly track the set of memtypes
> that can fit in the pagetable structures.
> 

I don't think there is anything fundamental, though.  The number of
types had more to do with what there was demand for.  I will look into it.

	-hpa



  reply	other threads:[~2014-07-16  0:00 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 [this message]
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
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=53C5C066.2060707@zytor.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.