On Sat, Oct 19, 2019 at 10:05 AM Goldwyn Rodrigues <rgold...@suse.de> wrote:
>
> From: Goldwyn Rodrigues <rgold...@suse.com>
>
> We are checking PagePrivate twice, once with lock and once without.
> Perform the check only once.
Have you checked if there's some performance degradation after
removing the check?
My guess is it's there to avoid taking the lock, as the lock can be
heavily used on a system under heavy load (maybe even if it's not too
heavy, since we generate a lot of dirty metadata due to cow).
The page may have been released after locking the mapping, that's why
we check it twice, and after unlocking we are sure it can not be
released due to taking a reference on the extent buffer.
Thanks.
>
> Signed-off-by: Goldwyn Rodrigues <rgold...@suse.com>
> ---
> fs/btrfs/extent_io.c | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c
> index cceaf05aada2..425ba359178c 100644
> --- a/fs/btrfs/extent_io.c
> +++ b/fs/btrfs/extent_io.c
> @@ -3959,9 +3959,6 @@ int btree_write_cache_pages(struct address_space
> *mapping,
> for (i = 0; i < nr_pages; i++) {
> struct page *page = pvec.pages[i];
>
> - if (!PagePrivate(page))
> - continue;
> -
> spin_lock(&mapping->private_lock);
> if (!PagePrivate(page)) {
> spin_unlock(&mapping->private_lock);
> --
> 2.16.4
>
--
Filipe David Manana,
“Whether you think you can, or you think you can't — you're right.”
