From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.6 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3EC5EC3404C for ; Tue, 18 Feb 2020 21:21:18 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id ED8B621D56 for ; Tue, 18 Feb 2020 21:21:17 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="L9ufQZtG" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org ED8B621D56 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 989BA6B0005; Tue, 18 Feb 2020 16:21:17 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 939316B0006; Tue, 18 Feb 2020 16:21:17 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 84F6B6B0007; Tue, 18 Feb 2020 16:21:17 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0009.hostedemail.com [216.40.44.9]) by kanga.kvack.org (Postfix) with ESMTP id 6A2C06B0005 for ; Tue, 18 Feb 2020 16:21:17 -0500 (EST) Received: from smtpin30.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 407C5283C for ; Tue, 18 Feb 2020 21:21:17 +0000 (UTC) X-FDA: 76504518594.30.blood30_7f9d6413b7234 X-HE-Tag: blood30_7f9d6413b7234 X-Filterd-Recvd-Size: 3654 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) by imf14.hostedemail.com (Postfix) with ESMTP for ; Tue, 18 Feb 2020 21:21:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20170209; h=In-Reply-To:Content-Type:MIME-Version :References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=0HtJTFPkdLwAcbGGhAHyzxa8a1mSgpc758IYlfDOg/k=; b=L9ufQZtGybPYd67zmz67Xgy4Tn mZsneK5DIi4+EdZSTDy3qMq6jC4G9yjF4A0m3HKQqgfmPcf89rxgAlz7TflzrDt+lPKQjG8DBB0Nc hFwG4XwkG9NeYBz6KYBZ58AKe0IfPIrYhHeqqinr+nlcKs9GdGtB8jhCcawcvPy3icitqNTTzH4jP ZCAGflog5kL6wL3IvL71BWNMv5PaAXyucj7tYF+EQU4HI4NEjXGWh1T+shXyemzhRpUXmIabqr29C 5LaP21DN5DNYTONx+gIE3+S5Zr0Asg51I2iJBLolcYDkCch1kyQ608fu1c/WOZsk9fwFBAcPrEAy8 FZTOuLoQ==; Received: from willy by bombadil.infradead.org with local (Exim 4.92.3 #3 (Red Hat Linux)) id 1j4AIt-0003y5-Bi; Tue, 18 Feb 2020 21:21:15 +0000 Date: Tue, 18 Feb 2020 13:21:15 -0800 From: Matthew Wilcox To: John Hubbard Cc: linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-btrfs@vger.kernel.org, linux-erofs@lists.ozlabs.org, linux-ext4@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, cluster-devel@redhat.com, ocfs2-devel@oss.oracle.com, linux-xfs@vger.kernel.org Subject: Re: [PATCH v6 01/19] mm: Return void from various readahead functions Message-ID: <20200218212115.GG24185@bombadil.infradead.org> References: <20200217184613.19668-1-willy@infradead.org> <20200217184613.19668-2-willy@infradead.org> <29d2d7ca-7f2b-7eb4-78bc-f2af36c4c426@nvidia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <29d2d7ca-7f2b-7eb4-78bc-f2af36c4c426@nvidia.com> X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue, Feb 18, 2020 at 01:05:29PM -0800, John Hubbard wrote: > This is an easy review and obviously correct, so: > > Reviewed-by: John Hubbard Thanks > Thoughts for the future of the API: > > I will add that I could envision another patchset that went in the > opposite direction, and attempted to preserve the information about > how many pages were successfully read ahead. And that would be nice > to have (at least IMHO), even all the way out to the syscall level, > especially for the readahead syscall. Right, and that was where I went initially. It turns out to be a non-trivial aount of work to do the book-keeping to find out how many pages were _attempted_, and since we don't wait for the I/O to complete, we don't know how many _succeeded_, and we also don't know how many weren't attempted because they were already there, and how many weren't attempted because somebody else has raced with us and is going to attempt them themselves, and how many weren't attempted because we just ran out of memory, and decided to give up. Also, we don't know how many pages were successfully read, and then the system decided to evict before the program found out how many were read, let alone before it did any action based on that. So, given all that complexity, and the fact that nobody actually does anything with the limited and incorrect information we tried to provide today, I think it's fair to say that anybody who wants to start to do anything with that information can delve into all the complexity around "what number should we return, and what does it really mean". In the meantime, let's just ditch the complexity and pretense that this number means anything.