On Wed, Apr 05, 2017 at 11:45:39AM -0500, Shiraz Saleem wrote:
> On Wed, Apr 05, 2017 at 09:23:57AM +0300, Leon Romanovsky wrote:
> > From: Artemy Kovalyov <artemyko@xxxxxxxxxxxx>
> >
> > Add IB_ACCESS_HUGETLB ib_reg_mr flag.
> > Hugetlb region registered with this flag
> > will use single translation entry per huge page.
> >
> > Signed-off-by: Artemy Kovalyov <artemyko@xxxxxxxxxxxx>
> > Signed-off-by: Leon Romanovsky <leon@xxxxxxxxxx>
> > ---
> > drivers/infiniband/core/umem.c | 2 +-
> > drivers/infiniband/core/umem_odp.c | 19 +++++++++++++++++--
> > include/rdma/ib_umem_odp.h | 6 ++++--
> > include/rdma/ib_verbs.h | 1 +
> > 4 files changed, 23 insertions(+), 5 deletions(-)
> >
> > @@ -315,6 +317,20 @@ int ib_umem_odp_get(struct ib_ucontext *context, struct ib_umem *umem)
> > if (!mm)
> > return -EINVAL;
> >
> > + if (access & IB_ACCESS_HUGETLB) {
> > + struct vm_area_struct *vma;
> > + struct hstate *h;
> > +
> > + vma = find_vma(mm, ib_umem_start(umem));
> > + if (!vma || !is_vm_hugetlb_page(vma))
> > + return -EINVAL;
> > + h = hstate_vma(vma);
> > + umem->page_shift = huge_page_shift(h);
> > + umem->hugetlb = 1;
>
> User memory buffer could span multiple VMAs right? So shouldn’t we check all VMAs of the umem
> before setting the hugetlb flag?
It depends on what do you want to achieve. Current implementation uses
best effort strategy and it assumes that user called to madvise
with MADV_HUGETLB before. In such case, all VMAs will have hugettlb
property in it. If the user calls madavise for partial umem region,
the application and ODP will continue to work, but won't efficient
in its memory usage.
Thanks
>
> > + } else {
> > + umem->hugetlb = 0;
> > + }
> > +
> > /* Prevent creating ODP MRs in child processes */
> > rcu_read_lock();
> > our_pid = get_task_pid(current->group_leader, PIDTYPE_PID);
Attachment:
signature.asc
Description: PGP signature
