Re: [PATCH] vduse: avoid using __GFP_NOFAIL

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Aug 6, 2024 at 11:10 AM Yongji Xie <xieyongji@xxxxxxxxxxxxx> wrote:
>
> On Tue, Aug 6, 2024 at 10:28 AM Jason Wang <jasowang@xxxxxxxxxx> wrote:
> >
> > On Mon, Aug 5, 2024 at 6:42 PM Yongji Xie <xieyongji@xxxxxxxxxxxxx> wrote:
> > >
> > > On Mon, Aug 5, 2024 at 4:24 PM Jason Wang <jasowang@xxxxxxxxxx> wrote:
> > > >
> > > > On Mon, Aug 5, 2024 at 4:21 PM Jason Wang <jasowang@xxxxxxxxxx> wrote:
> > > > >
> > > > > Barry said [1]:
> > > > >
> > > > > """
> > > > > mm doesn't support non-blockable __GFP_NOFAIL allocation. Because
> > > > > __GFP_NOFAIL without direct reclamation may just result in a busy
> > > > > loop within non-sleepable contexts.
> > > > > ""“
> > > > >
> > > > > Unfortuantely, we do that under read lock. A possible way to fix that
> > > > > is to move the pages allocation out of the lock into the caller, but
> > > > > having to allocate a huge number of pages and auxiliary page array
> > > > > seems to be problematic as well per Tetsuon [2]:
> > > > >
> > > > > """
> > > > > You should implement proper error handling instead of using
> > > > > __GFP_NOFAIL if count can become large.
> > > > > """
> > > > >
> > >
> > > I think the problem is it's hard to do the error handling in
> > > fops->release() currently.
> >
> > vduse_dev_dereg_umem() should be the same, it's very hard to allow it to fail.
> >
> > >
> > > So can we temporarily hold the user page refcount, and release it when
> > > vduse_dev_open()/vduse_domain_release() is executed. The kernel page
> > > allocation and memcpy can be done in vduse_dev_open() which allows
> > > some error handling.
> >
> > Just to make sure I understand this, the free is probably not the big
> > issue but the allocation itself.
> >
>
> Yes, so defer the allocation might be a solution.

Would you mind posting a patch for this?

>
> > And if we do the memcpy() in open(), it seems to be a subtle userspace
> > noticeable change? (Or I don't get how copying in vduse_dev_open() can
> > help here).
> >
>
> Maybe we don't need to do the copy in open(). We can hold the user
> page refcount until the inflight I/O is completed. That means the
> allocation of new kernel pages can be done in
> vduse_domain_map_bounce_page() and the release of old user pages can
> be done in vduse_domain_unmap_bounce_page().

This seems to be a subtle userspace noticeable behaviour?

> Of course, we still have
> a copy (old user page -> new user spage) if the daemon calls
> vduse_dev_reg_umem() again.
>
> Thanks,
> Yongji
>

Thanks






[Index of Archives]     [KVM Development]     [Libvirt Development]     [Libvirt Users]     [CentOS Virtualization]     [Netdev]     [Ethernet Bridging]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite Forum]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux