Re: [patch 12/13] GRU Driver V3 - export is_uv_system(), zap_page_range() & follow_page()

[Nick Piggin]

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


> > Using gup.c code I don't think will prevent your driver from getting
> > accepted. Conversely, I would not like the open coded page table walk
> > to go upstream...
>
> If that is the concensus, that is ok. How certain are we that gup.c will
> go into 2.6.27.

Linus sounded pretty happy to merge gup as soon as 2.6.27 opens
when I asked.


> Initially, I though it was cleaner to decouple the GRU 
> from gup.c & to wait until I had all the hugepage & ia64 issues resolved
> before trying to push the walker into the kernel.

If you're just getting things working in -mm I don't mind one way
or the other I guess. But it should not get merged like that.


> (The driver runs ok as 
> long as huge pages are not referenced. It detects attempts to reference
> hugepages and gives the user an error).
>
> We would also need a gup.c for ia64.

That may not be such a bad idea. Don't know if they have a spare pte bit.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/