Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Fri, 17 Jan 2020 12:05:36 +0100
From:   Jan Kara <jack@suse.cz>
To:     "yukuai (C)" <yukuai3@huawei.com>
Cc:     Jan Kara <jack@suse.cz>, hch@infradead.org,
        darrick.wong@oracle.com, linux-xfs@vger.kernel.org,
        linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
        houtao1@huawei.com, zhengbin13@huawei.com, yi.zhang@huawei.com
Subject: Re: [RFC] iomap: fix race between readahead and direct write
Message-ID: <20200117110536.GE17141@quack2.suse.cz>
References: <20200116063601.39201-1-yukuai3@huawei.com>
 <20200116153206.GF8446@quack2.suse.cz>
 <ce4bc2f3-a23e-f6ba-0ef1-66231cd1057d@huawei.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <ce4bc2f3-a23e-f6ba-0ef1-66231cd1057d@huawei.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Fri 17-01-20 17:39:03, yukuai (C) wrote:
> On 2020/1/16 23:32, Jan Kara wrote:
> > Thanks for the report and the patch. But the data integrity when mixing
> > buffered and direct IO like this is best effort only. We definitely do not
> > want to sacrifice performance of common cases or code complexity to make
> > cases like this work reliably.
> 
> In the patch, the only thing that is diffrent is that iomap_begin() will
> be called for each page. However, it seems the performance in sequential
> read didn't get worse. Is there a specific case that the performance
> will get worse?

Well, one of the big points of iomap infrastructure is that you call
filesystem once to give you large extent instead of calling it to provide
allocation for each page separately. The additional CPU overhead will be
visible if you push the machine hard enough. So IMHO the overhead just is
not worth it for a corner-case like you presented. But that's just my
opinion, Darrick and Christoph are definitive arbiters here...

								Honza

-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR