> Right, but then you need to set that in the VMA's, and thus gone is your
> nice fast g_u_p() that doesn't touch VMAs :-)
Registering memory is a slow path thing in the RDMA world. Speeding it
up is nice, so we make userspace do the madvise(VM_DONTCOPY) if it cares
but if it doesn't it can lea
On Wed, 2009-02-04 at 21:10 -0800, Roland Dreier wrote:
> > Note that g_u_p() has all sort of shortcommings... we were discussing
> > some of that recently due to bugs reported from the field.
> >
> > The problem mostly is that you cannot guarantee that the physical page
> > will remain mapped
> Note that g_u_p() has all sort of shortcommings... we were discussing
> some of that recently due to bugs reported from the field.
>
> The problem mostly is that you cannot guarantee that the physical page
> will remain mapped to that virtual address in the process. For example,
> if your
> get_user_pages() also gives us the vma back, and we can see from
> is_vm_hugetlb_page() (-- BTW can I just say that a function
> is_xxx_page() that operates on vmas is horribly misnamed --) that these
> pages all come from a hugetlb mapping, but figuring out the size of that
> mapping is I guess
> You should be able to find the head of a compound page using the
> compound_head() inline, so try
> PAGE_SIZE << compound_order(compound_head(page))
Thanks! Looks like that should be exactly what we need.
- R.
___
Linuxppc-dev mailing list
On Wed, 04 Feb 2009 11:11:22 -0800
Roland Dreier wrote:
> > > > huge_page_size(page_hstate(page))
>
> > > That would suit. I assume the intention is for that to be usable by
> > > driver modules on any architecture?
>
> > erm, you overestimate the amount of planning and forethought
On Wed, Feb 04, 2009 at 11:11:22AM -0800, Roland Dreier wrote:
> Heh. Looking into the implementation, it seems that I could actually do
> PAGE_SIZE << compound_order(page)
> directly (since there's no reason to go from size to hstate and back to
> size. I don't know all the details of thes
> > > huge_page_size(page_hstate(page))
> > That would suit. I assume the intention is for that to be usable by
> > driver modules on any architecture?
> erm, you overestimate the amount of planning and forethought which goes
> into these things ;)
> The lack of any EXPORT_SYMBOL
On Wed, 04 Feb 2009 12:50:48 +1100 Benjamin Herrenschmidt
>>> Do the generic hugetlbfs code provides such an API ? If not, we may need
>>> to add one.
On Wednesday 04 February 2009 16:13:29 Andrew Morton wrote:
>> I think it's something like
>> huge_page_size(page_hstate(page))
On Wed, Feb
On Tue, 03 Feb 2009 22:16:08 -0800 Roland Dreier wrote:
> > I think it's something like
> >
> >huge_page_size(page_hstate(page))
>
> That would suit. I assume the intention is for that to be usable by
> driver modules on any architecture?
>
erm, you overestimate the amount of planning
> I think it's something like
>
> huge_page_size(page_hstate(page))
That would suit. I assume the intention is for that to be usable by
driver modules on any architecture?
- R.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozl
On Wednesday 04 February 2009 16:13:29 Andrew Morton wrote:
> On Wed, 04 Feb 2009 12:50:48 +1100 Benjamin Herrenschmidt
> > Do the generic hugetlbfs code provides such an API ? If not, we may need
> > to add one.
>
> I think it's something like
>
> huge_page_size(page_hstate(page))
That wou
On Wed, 04 Feb 2009 12:50:48 +1100 Benjamin Herrenschmidt
wrote:
> On Tue, 2009-02-03 at 17:08 -0800, Roland Dreier wrote:
> > Forwarding Eli's patch below, since PowerPC guys may have missed it. I
> > guess the question for Ben et al is whether there is any issue with
> > exporting HPAGE_SHIFT
On Tue, 2009-02-03 at 17:08 -0800, Roland Dreier wrote:
> Forwarding Eli's patch below, since PowerPC guys may have missed it. I
> guess the question for Ben et al is whether there is any issue with
> exporting HPAGE_SHIFT for modules (can be EXPORT_SYMBOL_GPL if you feel
> it's an internal detail
Forwarding Eli's patch below, since PowerPC guys may have missed it. I
guess the question for Ben et al is whether there is any issue with
exporting HPAGE_SHIFT for modules (can be EXPORT_SYMBOL_GPL if you feel
it's an internal detail). It would probably make sense to roll this
change into the ml
15 matches
Mail list logo
