Re: [PATCH RFC v2] mm: Add f_ops->populate()

From: Jarkko Sakkinen
Date: Mon Mar 07 2022 - 08:01:12 EST


On Sun, Mar 06, 2022 at 03:24:56PM -0800, Andrew Morton wrote:
> On Sun, 6 Mar 2022 05:26:55 +0200 Jarkko Sakkinen <jarkko@xxxxxxxxxx> wrote:
>
> > Sometimes you might want to use MAP_POPULATE to ask a device driver to
> > initialize the device memory in some specific manner. SGX driver can use
> > this to request more memory by issuing ENCLS[EAUG] x86 opcode for each
> > page in the address range.
>
> Why is this useful? Please fully describe the benefit to kernel users.
> Convince us that the benefit justifies the code churn, maintenance
> cost and larger kernel footprint.
>
> Do we know of any other drivers which might use this?

Brutal honesty: I don't know if any other drivers would use this but
neither I would not be surprised if they did. The need for this might
very well be "masked" by ioctl API's. I was first proposing a ioctl
for this but Dave suggested to at least try out this route.

> > Add f_ops->populate() with the same parameters as f_ops->mmap() and make
> > it conditionally called inside call_mmap(). Update call sites
> > accodingly.
>
> spello

Thanks, I noticed that but did not want to spam with a new version just
because of that :-)

>
> > -static inline int call_mmap(struct file *file, struct vm_area_struct *vma)
> > +static inline int call_mmap(struct file *file, struct vm_area_struct *vma, bool do_populate)
> > {
> > - return file->f_op->mmap(file, vma);
> > + int ret = file->f_op->mmap(file, vma);
> > +
> > + if (!ret && do_populate && file->f_op->populate)
> > + ret = file->f_op->populate(file, vma);
> > +
> > + return ret;
> > }
>
> Should this still be inlined?

I think it might make sense at least to have call_mmap_populate() so and
mmap_region_populate() instead of putting that boolean parameter to every
flow (based on Greg's feedback). But only if this implementation approach
is used in the first place.

As said, I chose to use RFC to pinpoint a bottleneck for us, not claiming
that this would be the best possible way to work around it.

BR, Jarkko