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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3C386D1AD4B for ; Wed, 16 Oct 2024 11:57:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C75246B0089; Wed, 16 Oct 2024 07:57:50 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C24C96B008A; Wed, 16 Oct 2024 07:57:50 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B13BB6B008C; Wed, 16 Oct 2024 07:57:50 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 9009E6B0089 for ; Wed, 16 Oct 2024 07:57:50 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 9AFCF1A00E9 for ; Wed, 16 Oct 2024 11:57:32 +0000 (UTC) X-FDA: 82679315922.03.3266D48 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf26.hostedemail.com (Postfix) with ESMTP id 4AE70140008 for ; Wed, 16 Oct 2024 11:57:42 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=KLjmEU1L; dmarc=none; spf=none (imf26.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1729079751; a=rsa-sha256; cv=none; b=yz2HFCqxzo12DVT9+KSUx5e2VvKOVcH6GKoE5dpBpJz1mv782gtHkBY2xomCBt6+VmWFS4 SWX+brl/2iWvD4OPd2VYuNe4Q4R2XiXjkkS36E4BQ62MZ7+ps/TLWgrq1nX3FRScGYBdNX QffdIp5cifK/8YhokUUVj+oOGVuSSPw= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=KLjmEU1L; dmarc=none; spf=none (imf26.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1729079751; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=Mbl/u6ht4xnA85g84TEKGQpV8CYMroGPrfeh03GQbFs=; b=41TorReYCsmTgPhYsrFK+6bH1ku8OE0V+ztUJ301CSkcrkkGD6qmT2/9rnLXsc3/5iuKl/ 2G5wkrg7LBog4bd/fUJVRT32CFnLTcWWzYhdulAX7JKR3bOIssNTCf645ERuFBvlM3+1M/ lbERljO1HJNtlNQvBj2l/q5n273AFgY= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.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=Mbl/u6ht4xnA85g84TEKGQpV8CYMroGPrfeh03GQbFs=; b=KLjmEU1LZHa3oKp05sgxPZBHBq /jK+biCr/+fXjo7wfccH1jGK/Foq7RF8XUXQlfB9+ze3FyaruLXwyQwgYnNZqNTQmNt/9Lwp72yvb Sskuz2LMBP1JQBknhxbSzF2+qRcRdlA6CQpX66iOO+mtYEswaarXFmXZamtqVJfD0lGe9V0/Dna9j bm2jsWQgFO2LdQk8khPqI99eT3ccY9XI9q0O5t3ud/j31Wf60Zu93Z9uClMDaSaH0RmgCZdqilLqH TcWI4z2xu6euQgDo9vBcI4g12L5z5xMjQ2knrxBIkChnsxxS0py8JdZJE2W8MGX1gAaUngPmRAazQ L1O1gMfA==; Received: from willy by casper.infradead.org with local (Exim 4.98 #2 (Red Hat Linux)) id 1t12ev-00000007ptf-0xVU; Wed, 16 Oct 2024 11:57:45 +0000 Date: Wed, 16 Oct 2024 12:57:44 +0100 From: Matthew Wilcox To: "Pankaj Raghav (Samsung)" Cc: akpm@linux-foundation.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, mcgrof@kernel.org, gost.dev@samsung.com, Pankaj Raghav Subject: Re: Re: [PATCH v14] mm: don't set readahead flag on a folio when lookahead_size > nr_to_read Message-ID: References: <20241015164106.465253-1-kernel@pankajraghav.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 4AE70140008 X-Stat-Signature: 8h96gds11jgf8x7m7gfgbbbtaiux6hjo X-Rspam-User: X-HE-Tag: 1729079862-142837 X-HE-Meta: U2FsdGVkX18l9ndKToaXCpNNHZ+tIdx7G0cHQwJW9bXArLrLxZkmTrX+yDADLid9HhPsGhBEJKi/3O8BpM/Y4WfE3Nm8YnjEA2gcNUulRHWL9UP0tDgfZ+aBfK5yz612FAM5oObva38i5BVqnQV374UD8bgbYnoxMbPyNxo1mmZEInbK6f6fO1k7qHrIsmpCJOrzCy/5CCGozji0urUNNV5+BK1Ra0x8UCayQ2BZFJp0Fh/bjWbfEYKE7rYWIGcZVEhHhRWSsNJF5yoEKNF/Pl0h4+xNU7EJlk9F4+0ShdHRJku0Sjwr1jArGTnvSAf5F4SWWqwHBoPOsMkujYnEdQSIeifLxGcAMVtE6tW5mT9eiwGrdNyDRhXr+VTBaUoxb3XKvw6AuT/dcc/uDQvS9MODDU9CBizbQy8BYXk3A+uHcCZ2FWV9NrxWEnPkkPyG3yrcrg8WsZVNBVbeoLDXo1Y06P8eBP1aDqpHQe8hNOK9q1mgzJN0PCz2/cK+0VvExNwLk3roM9tnbHmDtLc+KugoOyKoxu4uoB2ctA1+T9ZnfZSlPG32R5SEZusyLzqQL9QmIzqVO7zZ9Tc60h33R7BvVxc2sabKZajqzVawAHbBeX6ReltAtrSB7dv3RERHqT59XIYf3xXdOQOp642V9/tInYTJCpBv5RkxRiojZoAEeiMcWeuwdPwt5tmcB+Br6n6GOVUvoYW87SlhLpPn5RT2ZMwxMcFZB5/NjCn+ob4UHHwoZvEL1188c9/Q225eIIOpQpWURJ/pFkNMGtcWtz3JW5ZDUlmLhIpzHXM+tfKhER5ZKfIyFOzHHvYI+OTFnt31vOAcnSe6L0yg/wbgo7snk+TRNdTVk7wQrFfriDYJ9HJUAocNAKkGxKR/PII3tHVxWGxWbhkYNxhd8TF0if/Ms/ihEgNihcDgrkfYst1WONbQrMgA4cc3XkgjUwbGuSUw7hZkJ9xjCBecIZI JCSILU/S Vf6HRddhIOP3+ngdPcn4GOb22RW+lQNwbUX083/HcjdkUQUg5/5LywmAY8dAhf7Zq8vI/rFhw0eGRUfPM+GVU54m7QuClkt0g++SsmkSoB9mo91vyE30sl5g50fVo43FutMGfeUJaFdfLqdbWJaTZujh9uu7kg9RgGOtNtrAwW76J4Fw7K45fmz6Zs5zJLj1Y2mK6p1elVb4RIQxZLc1T7hx2/P9G6rtVSr5hkPCP16/3IWx/0J9QL3Pz2+HnPL6GBmXvDRnFLrRHhe6SlrGTmqt4Jg== 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: List-Subscribe: List-Unsubscribe: On Wed, Oct 16, 2024 at 03:35:27PM +0530, Pankaj Raghav (Samsung) wrote: > > > - The current calculation for `mark` with mapping_min_order > 0 gives > > > incorrect results when lookahead_size > nr_to_read due to rounding > > > up operation. > > > > > > Explicitly initialize `mark` to be ULONG_MAX and only calculate it > > > when lookahead_size is within the readahead window. > > > > You haven't really spelled out the consequences of this properly. > > Perhaps a worked example would help. > > Got it. I saw this while running generic/476 on XFS with 64k block size. > > Let's assume the following values: > index = 128 > nr_to_read = 16 > lookahead_size = 28 > mapping_min_order = 4 (16 pages) > > The lookahead_size is actually lying outside the current readahead > window. The calculation without this patch will result in incorrect mark > as follows: > > ra_folio_index = round_up(128 + 16 - 28, 16) = 128; > mark = 128 - 128 = 0; > > So we will be marking the folio on 0th index with RA flag, even though > we shouldn't have. Does that make sense? But we don't go back and find the folio for index 0. We only consider the folios we're actually reading for marking. So if 'mark' lies outside the readahead window, we simply won't mark any of them. So I don't think your patch changes anything. Or did I miss something?