From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f180.google.com (mail-pl1-f180.google.com [209.85.214.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6DDC4627FD for ; Tue, 13 Feb 2024 22:09:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.180 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1707862198; cv=none; b=gCO74/VQF7vlXwMCBznTfQcbLL0w+leVpszF3VGYqpTmpLgH/zBbSz5qLExkuP5o9vnIrX/ciAdt1PEnkjtO4QQaq6p8Ww2LkeD1EWkILCdfIRkx5xRtSBylsRn7IpWv221BoK3GPXg10TFsR0yD4DzkJXrUdbKbVd4vuyPId2w= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1707862198; c=relaxed/simple; bh=W8CKXLRXzCPIbeiYhYvLTtnfDtGO8TmN5pF7T5jBlOE=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=hS7UvTO87II3WgTipksaGmB8S/kNtJBzbdFkake5MJKOfadkmsIXV4Y1VQmOLLJxFS4GxVXmf9yTmGHo60UEjpNZEW73U4SEuheaMxZcXhKFnzWpDGrjj1x6YNzjbROXHyJcvULcjUm3Re+0oNpZ7glESa94eFo5M4oVBEy+JsI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=fromorbit.com; spf=pass smtp.mailfrom=fromorbit.com; dkim=pass (2048-bit key) header.d=fromorbit-com.20230601.gappssmtp.com header.i=@fromorbit-com.20230601.gappssmtp.com header.b=ErAo2G/h; arc=none smtp.client-ip=209.85.214.180 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=fromorbit.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=fromorbit.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=fromorbit-com.20230601.gappssmtp.com header.i=@fromorbit-com.20230601.gappssmtp.com header.b="ErAo2G/h" Received: by mail-pl1-f180.google.com with SMTP id d9443c01a7336-1d70b0e521eso36992735ad.1 for ; Tue, 13 Feb 2024 14:09:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fromorbit-com.20230601.gappssmtp.com; s=20230601; t=1707862196; x=1708466996; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=KHrAkUvYa6loZ8pQ9MvgMBm7Y/FcJKqjouZpJd3Deg4=; b=ErAo2G/hJ/ZxmlbuU9tjLAdCWW2ovpypumay2kxa3Q4ub7fwWqDo94g2yvKnIrlZG8 eCCec52cAgWrPjktmrsyQqTbFm+lCLeW8GJfPmQi6ekECy4qrXtGKc/XgQICTzaNqYfY LwVBbXwijBQR7+Bq1HCkbdaj101v2hC7wMYESLg7FuYSGh7KWkPMeK/fLri4DZb38mGR Co06+kfrnFyjim5orX5wksGvdzVyN5NvF45lMsb4D6wHE9AvbPBMcgsW25Nv42awDlak jrbjUdD72BLFExhEtghrcyK9kFNBDoxc3iv11fFQpvtnJngncV8BMiGjn45IVsp5ptsr 9puQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1707862196; x=1708466996; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=KHrAkUvYa6loZ8pQ9MvgMBm7Y/FcJKqjouZpJd3Deg4=; b=WhOk/wUGOqNnNFQcABq92uZv6N7nMjeM8nf6DL201ORtIKmyZ9EzrfEd8toCqwU42+ ElZCBXVMBmWUfaRjefcEakAmLGo0swCNMRTTlHkPErkx9AArTLLyk8UqQWNM9kTaQyZB /lP9C41wSJh5Y75QSH5zqPYBm8gSWP00/fu0fzVeqZZdfLFKS+G7xH0mOp8myxRoZB31 E7L5BVZXwvQJOFVpajEVp1+fWZZvsUTHX2XnPVr0Qq7ZWAxzDGb/qp1paA0UZ3MIkbCE RcBbRuML8gJ2aw0fh1ek1MYu30vToetmFsm3eJV/WuubtDSdIv0pJ8FA5bv+als98La7 Cb/w== X-Forwarded-Encrypted: i=1; AJvYcCVCDUkOb8WUDG3lad5orWLUsPGAV1ComFAzLzliW3iOE3WVmdS6vOurFimQ6f1WjARg/7x80qYOYBXjLa+AUS4kLLRbz9hn7hKcqvcv X-Gm-Message-State: AOJu0YwTFthNBgzkIFB6FHacsg1cnZkulp9dZo+W5d9JdBnl7NBzyl2e B/kjVHSsCMypQtTcbgzrWjBnxpNmACFTixDjj4EzG5V3SMTHhn5SXofNL2hnGUTdK86dnObXglk 9 X-Google-Smtp-Source: AGHT+IGgqUUsjn257/XY2P22HF+jK6l4KCqtveCToMslA6YTTEIfSnRD2gkjjAU8E2S7/q7gFf6VFw== X-Received: by 2002:a17:902:e5d0:b0:1d9:14fb:d142 with SMTP id u16-20020a170902e5d000b001d914fbd142mr1287192plf.32.1707862196652; Tue, 13 Feb 2024 14:09:56 -0800 (PST) X-Forwarded-Encrypted: i=1; AJvYcCU0ESVTZZSVdnxEus9YiyUaZmdXAgx/Xl1gU3CR6MVu9J4mZ+RaM5oZScWBYV6lzac7Dd70RSYsCsBl6RjMuqdB1SViohyMqK9AjP/0Nubsg9spL66O5OJ9Ilh7PBEprTOECIhR4U6k6dNjIhuTIXL/2IwZhep/x5ggajcUnMC/bk5OAyhKaCOSKT/Fhh0h9gzWNpDTA1yDdR0F3fWjhBlbaaNq9IE4qPiAV6YN6DHzTGkL0o98qmyE1stg1SerRm983++Xdcd9i9cIKm6UmxT76yjpRoBGWL4/rDpAF6zXb4cbDPR+ZUd4YdnTtJs5vpMd34GoiUONqcfhPSbbZ7BjT1L6j/ImosHNqAYul6ynTtmVdRe1uBCKFj0KHY0Z7CP/NUPO++Ga4G3eJACOq5GzM8gHlKkeW/vvvzQ= Received: from dread.disaster.area (pa49-181-38-249.pa.nsw.optusnet.com.au. [49.181.38.249]) by smtp.gmail.com with ESMTPSA id jc19-20020a17090325d300b001db2ff16acasm1894517plb.128.2024.02.13.14.09.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 13 Feb 2024 14:09:56 -0800 (PST) Received: from dave by dread.disaster.area with local (Exim 4.96) (envelope-from ) id 1ra0yP-0067hn-1k; Wed, 14 Feb 2024 09:09:53 +1100 Date: Wed, 14 Feb 2024 09:09:53 +1100 From: Dave Chinner To: "Pankaj Raghav (Samsung)" Cc: linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org, mcgrof@kernel.org, gost.dev@samsung.com, akpm@linux-foundation.org, kbusch@kernel.org, djwong@kernel.org, chandan.babu@oracle.com, p.raghav@samsung.com, linux-kernel@vger.kernel.org, hare@suse.de, willy@infradead.org, linux-mm@kvack.org Subject: Re: [RFC v2 04/14] readahead: set file_ra_state->ra_pages to be at least mapping_min_order Message-ID: References: <20240213093713.1753368-1-kernel@pankajraghav.com> <20240213093713.1753368-5-kernel@pankajraghav.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240213093713.1753368-5-kernel@pankajraghav.com> On Tue, Feb 13, 2024 at 10:37:03AM +0100, Pankaj Raghav (Samsung) wrote: > From: Luis Chamberlain > > Set the file_ra_state->ra_pages in file_ra_state_init() to be at least > mapping_min_order of pages if the bdi->ra_pages is less than that. > > Signed-off-by: Luis Chamberlain > --- > mm/readahead.c | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/mm/readahead.c b/mm/readahead.c > index 2648ec4f0494..4fa7d0e65706 100644 > --- a/mm/readahead.c > +++ b/mm/readahead.c > @@ -138,7 +138,12 @@ > void > file_ra_state_init(struct file_ra_state *ra, struct address_space *mapping) > { > + unsigned int min_nrpages = mapping_min_folio_nrpages(mapping); > + unsigned int max_pages = inode_to_bdi(mapping->host)->io_pages; > + > ra->ra_pages = inode_to_bdi(mapping->host)->ra_pages; > + if (ra->ra_pages < min_nrpages && min_nrpages < max_pages) > + ra->ra_pages = min_nrpages; Why do we want to clamp readahead in this case to io_pages? We're still going to be allocating a min_order folio in the page cache, but it is far more efficient to initialise the entire folio all in a single readahead pass than it is to only partially fill it with data here and then have to issue and wait for more IO to bring the folio fully up to date before we can read out data out of it, right? -Dave. -- Dave Chinner david@fromorbit.com