Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp1261887ybl; Sat, 18 Jan 2020 22:57:30 -0800 (PST) X-Google-Smtp-Source: APXvYqw+xuj15EHkxk6UayCA9+nYa3/osMF0/Emy6tjugKNxS8R87+WZKTxyoC/zY3RP9iK2k/fI X-Received: by 2002:a05:6830:2053:: with SMTP id f19mr11474849otp.193.1579417049893; Sat, 18 Jan 2020 22:57:29 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1579417049; cv=none; d=google.com; s=arc-20160816; b=KgSnGDDnEZAz9xWw/gxMNRyN/o124Q/KOz/L6egH31SNWWOLrGJQ/r5GhtUdoCm0y+ NUoaF84aDa+wKV72Fy/VmMBtTAfG477x+ixe0t8Nurqr9zz29pBg7ufI2FAqzyk6YQQl 6J9LDv+U0HNE3GCV7d/aVkeHXfCHJ559sqqh3reIEMxcRA2vsMZhDtdu2SrYiX1K3Kin AH0dmV1h43/0l6uj/9cny/35+P6jlBjmzzF3o/wLKcx4tFkdkWb6x2p2aXAERUGYpCAv yJ9ZcNOVoMYsST3VEDhFCAcnQ4XrbKYIXXnfV7gQR0B+3XqLyZkuI70CL3iqDYLQRvwf iabA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:in-reply-to :mime-version:user-agent:date:message-id:from:references:cc:to :subject; bh=8/yv40h+JyECUrX6kuURHfuPy7QjHCUecVkYJeOzr1k=; b=oX7ANp4/zmOS1IUimxb/jmQS/a4o8ZgaFIRjjIg9HJ1E0PwYYaLmO9Zr2yRjPe5TZl ySmzMGXuuBkPN2s1dOvcQXZhOVc03XUyKwsNT4Nuf1FJ3yjEuGqly4H/542lzZGdWfWz 0K53HrxnESIcaXeG/Ug+uS9hysOoTh6NrWLa1oX9z+Lpx559EWU4RsIGTLNw3OriYt95 FnKU+DN8Jm8hRI7VSriBxV+0/uc9d7JT6oWmRC0vd1VKce18eSDCGMvwz5yMMFQKKEjG EnT51oIN/j0p39pqPzi2f4/f7xbzBrPaaZ4QH3VY+Jv409kf/JVVkt8zJ8SZaz0ot6N3 I12Q== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d21si16341812oic.168.2020.01.18.22.57.07; Sat, 18 Jan 2020 22:57:29 -0800 (PST) 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; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726586AbgASGzY (ORCPT + 99 others); Sun, 19 Jan 2020 01:55:24 -0500 Received: from szxga06-in.huawei.com ([45.249.212.32]:52042 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726396AbgASGzY (ORCPT ); Sun, 19 Jan 2020 01:55:24 -0500 Received: from DGGEMS401-HUB.china.huawei.com (unknown [172.30.72.59]) by Forcepoint Email with ESMTP id 8D746BB766B624487531; Sun, 19 Jan 2020 14:55:21 +0800 (CST) Received: from [127.0.0.1] (10.173.220.96) by DGGEMS401-HUB.china.huawei.com (10.3.19.201) with Microsoft SMTP Server id 14.3.439.0; Sun, 19 Jan 2020 14:55:15 +0800 Subject: Re: [RFC] iomap: fix race between readahead and direct write To: Matthew Wilcox CC: , , , , , , , References: <20200116063601.39201-1-yukuai3@huawei.com> <20200118230826.GA5583@bombadil.infradead.org> <20200119014213.GA16943@bombadil.infradead.org> <64d617cc-e7fe-6848-03bb-aab3498c9a07@huawei.com> <20200119061402.GA7301@bombadil.infradead.org> From: "yukuai (C)" Message-ID: Date: Sun, 19 Jan 2020 14:55:14 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <20200119061402.GA7301@bombadil.infradead.org> Content-Type: text/plain; charset="gbk"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.173.220.96] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2020/1/19 14:14, Matthew Wilcox wrote: > I don't understand your reasoning here. If another process wants to > access a page of the file which isn't currently in cache, it would have > to first read the page in from storage. If it's under readahead, it > has to wait for the read to finish. Why is the second case worse than > the second? It seems better to me. Thanks for your response! My worries is that, for example: We read page 0, and trigger readahead to read n pages(0 - n-1). While in another thread, we read page n-1. In the current implementation, if readahead is in the process of reading page 0 - n-2, later operation doesn't need to wait the former one to finish. However, later operation will have to wait if we add all pages to page cache first. And that is why I said it might cause problem for performance overhead. > At the same time, the iomap code is switched from ->readpages to > ->readahead, so yes, the pages are added to the page cache. Yes, it's not a problem in your implementation. Thanks! Yu Kuai