MIME-Version: 1.0
References: <17c5adfe5ea.12f1be94625921.4478415437452327206@mykernel.net>
 <CAJfpegt4jZpSCXGFk2ieqUXVm3m=ng7QtSzZp2bXVs07bfrbXg@mail.gmail.com>
 <17d268ba3ce.1199800543649.1713755891767595962@mykernel.net>
 <CAJfpegttQreuuD_jLgJmrYpsLKBBe2LmB5NSj6F5dHoTzqPArw@mail.gmail.com>
 <17d2c858d76.d8a27d876510.8802992623030721788@mykernel.net>
 <17d31bf3d62.1119ad4be10313.6832593367889908304@mykernel.net>
 <20211118112315.GD13047@quack2.suse.cz> <17d32ecf46e.124314f8f672.8832559275193368959@mykernel.net>
 <20211118164349.GB8267@quack2.suse.cz> <17d36d37022.1227b6f102736.1047689367927335302@mykernel.net>
 <20211130112206.GE7174@quack2.suse.cz> <17d719b79f9.d89bf95117881.5882353172682156775@mykernel.net>
In-Reply-To: <17d719b79f9.d89bf95117881.5882353172682156775@mykernel.net>
From:   Amir Goldstein <amir73il@gmail.com>
Date:   Tue, 30 Nov 2021 21:04:59 +0200
Message-ID: <CAOQ4uxidK-yDMZoZtoRwTZLgSTr1o2Mu2L55vJRNJDLV0-Sb1w@mail.gmail.com>
Subject: Re: [RFC PATCH v5 06/10] ovl: implement overlayfs' ->write_inode operation
To:     Chengguang Xu <cgxu519@mykernel.net>
Cc:     Jan Kara <jack@suse.cz>, Miklos Szeredi <miklos@szeredi.hu>,
        linux-fsdevel <linux-fsdevel@vger.kernel.org>,
        overlayfs <linux-unionfs@vger.kernel.org>,
        linux-kernel <linux-kernel@vger.kernel.org>,
        ronyjin <ronyjin@tencent.com>,
        charliecgxu <charliecgxu@tencent.com>,
        Vivek Goyal <vgoyal@redhat.com>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

>  > I was thinking about this a bit more and I don't think I buy this
>  > explanation. What I rather think is happening is that real work for syncfs
>  > (writeback_inodes_sb() and sync_inodes_sb() calls) gets offloaded to a flush
>  > worker. E.g. writeback_inodes_sb() ends up calling
>  > __writeback_inodes_sb_nr() which does:
>  >
>  > bdi_split_work_to_wbs()
>  > wb_wait_for_completion()
>  >
>  > So you don't see the work done in the times accounted to your test
>  > program. But in practice the flush worker is indeed burning 1.3s worth of
>  > CPU to scan the 1 million inode list and do nothing.
>  >
>
> That makes sense. However, in real container use case,  the upper dir is always empty,
> so I don't think there is meaningful difference compare to accurately marking overlay
> inode dirty.
>

It's true the that is a very common case, but...

> I'm not very familiar with other use cases of overlayfs except container, should we consider
> other use cases? Maybe we can also ignore the cpu burden because those use cases don't
> have density deployment like container.
>

metacopy feature was developed for the use case of a container
that chowns all the files in the lower image.

In that case, which is now also quite common, all the overlay inodes are
upper inodes.

What about only re-mark overlay inode dirty if upper inode is dirty or is
writeably mmapped.
For other cases, it is easy to know when overlay inode becomes dirty?
Didn't you already try this?

Thanks,
Amir.