Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Fri, 31 Jul 2020 07:59:41 +0100
From:   Christoph Hellwig <hch@infradead.org>
To:     Matthew Wilcox <willy@infradead.org>
Cc:     Yu Kuai <yukuai3@huawei.com>, hch@infradead.org,
        darrick.wong@oracle.com, linux-xfs@vger.kernel.org,
        linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
        yi.zhang@huawei.com
Subject: Re: [RFC PATCH] iomap: add support to track dirty state of sub pages
Message-ID: <20200731065941.GD25674@infradead.org>
References: <20200730011901.2840886-1-yukuai3@huawei.com>
 <20200730031934.GA23808@casper.infradead.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20200730031934.GA23808@casper.infradead.org>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Thu, Jul 30, 2020 at 04:19:34AM +0100, Matthew Wilcox wrote:
> On Thu, Jul 30, 2020 at 09:19:01AM +0800, Yu Kuai wrote:
> > +++ b/fs/iomap/buffered-io.c
> > @@ -29,7 +29,9 @@ struct iomap_page {
> >  	atomic_t		read_count;
> >  	atomic_t		write_count;
> >  	spinlock_t		uptodate_lock;
> > +	spinlock_t		dirty_lock;
> 
> No need for a separate spinlock.  Just rename uptodate_lock.  Maybe
> 'bitmap_lock'.

Agreed.

> 
> >  	DECLARE_BITMAP(uptodate, PAGE_SIZE / 512);
> > +	DECLARE_BITMAP(dirty, PAGE_SIZE / 512);
> 
> This is inefficient and poses difficulties for the THP patchset.
> Maybe let the discussion on removing the ->uptodate array finish
> before posting another patch for review?

I really don't think we can kill the uptodate bit.   But what we can
do is have on bitmap array (flex size as in your prep patches) and just
alternating bits for uptodate and dirty.