Re: [PATCH v11] ovl: Improving syncfs efficiency

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

 



On Thu, Apr 16, 2020 at 9:21 AM Miklos Szeredi <miklos@xxxxxxxxxx> wrote:
>
> On Thu, Apr 16, 2020 at 8:09 AM Chengguang Xu <cgxu519@xxxxxxxxxxxx> wrote:
> >
> >  ---- 在 星期四, 2020-04-16 03:19:50 Miklos Szeredi <miklos@xxxxxxxxxx> 撰写 ----
> >  > On Mon, Feb 10, 2020 at 4:10 AM Chengguang Xu <cgxu519@xxxxxxxxxxxx> wrote:
>
> >  > > +               if (current->flags & PF_MEMALLOC) {
> >  > > +                       spin_lock(&inode->i_lock);
> >  > > +                       ovl_set_flag(OVL_WRITE_INODE_PENDING, inode);
> >  > > +                       wqh = bit_waitqueue(&oi->flags,
> >  > > +                                       OVL_WRITE_INODE_PENDING);
> >  > > +                       prepare_to_wait(wqh, &wait.wq_entry,
> >  > > +                                       TASK_UNINTERRUPTIBLE);
> >  > > +                       spin_unlock(&inode->i_lock);
> >  > > +
> >  > > +                       ovl_wiw.inode = inode;
> >  > > +                       INIT_WORK(&ovl_wiw.work, ovl_write_inode_work_fn);
> >  > > +                       schedule_work(&ovl_wiw.work);
> >  > > +
> >  > > +                       schedule();
> >  > > +                       finish_wait(wqh, &wait.wq_entry);
> >  >
> >  > What is the reason to do this in another thread if this is a PF_MEMALLOC task?
> >
> > Some underlying filesystems(for example ext4) check the flag in ->write_inode()
> > and treate it as an abnormal case.(warn and return)
> >
> > ext4_write_inode():
> >         if (WARN_ON_ONCE(current->flags & PF_MEMALLOC) ||
> >                 sb_rdonly(inode->i_sb))
> >                         return 0;
> >
> > overlayfs inodes are always keeping clean even after wring/modifying  upperfile ,
> > so they are right target of kswapd  but in the point of lower layer, ext4 just thinks
> > kswapd is choosing a wrong dirty inode to reclam memory.
>
> I don't get it.  Why can't overlayfs just skip the writeback of upper
> inode in the reclaim case?  It will be written back through the normal
> relcaim channels.

And how do we get reclaim on overlay inode at all?   Overlay inodes
will get evicted immediately after their refcount drops to zero, so
there's absolutely no chance that memory reclaim will encounter them,
no?

Thanks,
Miklos




[Index of Archives]     [Linux Filesystems Devel]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux