linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Jack Steiner <steiner@sgi.com>
To: Nick Piggin <nickpiggin@yahoo.com.au>
Cc: Hugh Dickins <hugh@veritas.com>,
	Christoph Hellwig <hch@infradead.org>,
	cl@linux-foundation.org, akpm@osdl.org,
	linux-kernel@vger.kernel.org, mingo@elte.hu, tglx@linutronix.de,
	holt@sgi.com, andrea@qumranet.com, linux-mm@kvack.org
Subject: Re: [patch 12/13] GRU Driver V3 -  export is_uv_system(), zap_page_range() & follow_page()
Date: Thu, 10 Jul 2008 12:20:36 -0500	[thread overview]
Message-ID: <20080710172036.GB5972@sgi.com> (raw)
In-Reply-To: <200807110252.00887.nickpiggin@yahoo.com.au>

On Fri, Jul 11, 2008 at 02:52:00AM +1000, Nick Piggin wrote:
> On Friday 11 July 2008 02:33, Jack Steiner wrote:
> > On Fri, Jul 11, 2008 at 12:21:28AM +1000, Nick Piggin wrote:
> > > On Thursday 10 July 2008 23:29, Jack Steiner wrote:
> > > > On Thu, Jul 10, 2008 at 05:31:54PM +1000, Nick Piggin wrote:
> > > > > On Thursday 10 July 2008 05:11, Jack Steiner wrote:
> > > > > > I'll post the new GRU patch in a few minutes.
> > > > >
> > > > > It looks broken to me. How does it determine whether it has a
> > > > > normal page or not?
> > > >
> > > > Right. Hugepages are not currently supported by the GRU. There is code
> > > > that I know is missing/broken in this path. I'm trying to get the core
> > > > driver accepted, then I'll get the portion dealing with hugepages
> > > > working.
> > >
> > > Oh, I meant "normal" pages as in vm_normal_page(), or is there some
> > > other reason this codepath is exempt from them?
> >
> > Maybe...
> >
> > The GRU deals with cacheable memory only (the check is currently missing).
> > What is the proper way to catch a reference to a PTE that maps something
> > other than normal cacheable memory. Note that we support XPMEM. Some
> > cacheable memory that is valid for GRU references will be memory located on
> > other partitions. No page struct entries will exist nor will the physical
> > address ranges be known to the kernel. (Not in efi/e820 tables).
> >
> > One idea that I had was to use the attributes of the PTE. Is there
> > better way. vm_flags? ???
> >
> > Ideas???
> 
> lockless gup checks for struct page by checking a bit in the pte.
> This should be enough to guarantee  it is cacheable memory (unless
> another driver has done something tricky like set the the page's
> cache attributes to UC or WC -- I don't know if there is a way to
> completely avoid all corner cases).
> 

The GRU itself has no need to reference the page struct.
However, it WILL reference valid ptes that represent pages imported from
other SSIs via xpmem. These will have cacheable ptes but no page structs.

Maybe checking the pte attributes is the best way to do the check.

If we take this approach, what is a good API for the gup.c walker?
Return the pte attributes?

	int get_user_pte(struct mm_struct *mm, unsigned long address,
	        int write, unsigned long *paddr, int *pageshift, pgprot_t *prot)

The GRU would enforce the check for cacheable access.

--- jack

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

  reply	other threads:[~2008-07-10 17:20 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20080703213348.489120321@attica.americas.sgi.com>
     [not found] ` <20080703213633.890647632@attica.americas.sgi.com>
     [not found]   ` <20080704073926.GA1449@infradead.org>
2008-07-07 14:39     ` Jack Steiner
2008-07-07 14:54       ` Andrea Arcangeli
2008-07-07 16:29       ` Hugh Dickins
2008-07-07 16:53         ` Jack Steiner
2008-07-08  2:16           ` Nick Piggin
2008-07-09 19:11             ` Jack Steiner
2008-07-10  7:31               ` Nick Piggin
2008-07-10 13:29                 ` Jack Steiner
2008-07-10 14:21                   ` Nick Piggin
2008-07-10 16:33                     ` Jack Steiner
2008-07-10 16:52                       ` Nick Piggin
2008-07-10 17:20                         ` Jack Steiner [this message]
2008-07-11  3:30                           ` Nick Piggin
2008-07-07 18:58         ` Arjan van de Ven
2008-07-07 19:29           ` Jack Steiner
2008-07-07 21:03             ` Andrea Arcangeli
2008-07-07 17:58     ` Jack Steiner

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=20080710172036.GB5972@sgi.com \
    --to=steiner@sgi.com \
    --cc=akpm@osdl.org \
    --cc=andrea@qumranet.com \
    --cc=cl@linux-foundation.org \
    --cc=hch@infradead.org \
    --cc=holt@sgi.com \
    --cc=hugh@veritas.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mingo@elte.hu \
    --cc=nickpiggin@yahoo.com.au \
    --cc=tglx@linutronix.de \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox