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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id DAC6DC4332F for ; Thu, 31 Mar 2022 19:08:06 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239589AbiCaTJx (ORCPT ); Thu, 31 Mar 2022 15:09:53 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51378 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234157AbiCaTJt (ORCPT ); Thu, 31 Mar 2022 15:09:49 -0400 Received: from mail-qv1-xf33.google.com (mail-qv1-xf33.google.com [IPv6:2607:f8b0:4864:20::f33]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B709821C727 for ; Thu, 31 Mar 2022 12:08:00 -0700 (PDT) Received: by mail-qv1-xf33.google.com with SMTP id ke15so303401qvb.11 for ; Thu, 31 Mar 2022 12:08:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg-org.20210112.gappssmtp.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=3OVG7rRs2TdxNhin07a4J/J4tSbwW3zVKWCQEqpy4T0=; b=RG4lduE77Jx8ZvyFt0EEudaFQPE1BG1QemD1WbZ9kW59cgVUqy0SCXMOSppS+G6cVf cxktuXi0BZS0Tx2g7D5YSybqxaGh43sibMhPHWEp+pI1F9ZrBxIKh8ykoQvHOKyatXvi O83/FHYqSuuR0U8E17Cc4cdXkpTR6pEf2jFCoCT7d88iTIOd+dNKFkCcAYW9QHVsQFtZ K7yZlpPoEdc/+L/xsgIOY3A4kPPItFYk+hrCwGpVsIebdDQErh3Bi962ANb6E/rDZx2o Rp+I8NRtEKfZAPWAMQpiN91TqH2SD1pTEFUNOiyi1jSOg0G78Ifnrn76h8iD1lTxDKk2 ZFDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=3OVG7rRs2TdxNhin07a4J/J4tSbwW3zVKWCQEqpy4T0=; b=0OQjeMls1ZMPIsQQ8DeqQQxXhm+7PnHCOPSXDYKijfhIt23+hSFscPzvNGvsXkIvON fZUEM3QkEcGSmwrrP7X65His9TETeCWT4PzA/yfT1DylNBVglNYUAdf3SB2f+qKo11y+ 7U5yw+QJKBcikpM6tvCFgZpMrkvzCsO7aO76ya7pooko09NEBYMizyQ4F5EhTGqbL6l8 qaprcao1M3MtinAmKryKLHxMwtQR8la3WYNtzdWDz/W/wvGrwMfSpJzULsl/rn2X+oNa 3snAdDpQ9ck2K/G2dFS3D0wCB14gUAvajt4/4P1CVwi89c9MbB+3Mmfh1/BfMjBTz085 b6rg== X-Gm-Message-State: AOAM530Qgwt6KVziIKDD8wL0Vj4rVQpt6kAkTegtHnkuflGLD4TJ3Rok fZ8K3BdoPy+lvy4JlXuRgTvV8A== X-Google-Smtp-Source: ABdhPJyZsiZ6vcPqXb9JIU/bdKv1RqimR5mlcEfT2c6Phpz4SDQIQ6ZLZZoYSIFpXtcU9pAJJXVoNg== X-Received: by 2002:a05:6214:766:b0:441:a5df:8ace with SMTP id f6-20020a056214076600b00441a5df8acemr5388121qvz.87.1648753679514; Thu, 31 Mar 2022 12:07:59 -0700 (PDT) Received: from localhost (cpe-98-15-154-102.hvc.res.rr.com. [98.15.154.102]) by smtp.gmail.com with ESMTPSA id b29-20020a05620a271d00b0067e0c273331sm78539qkp.111.2022.03.31.12.07.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 31 Mar 2022 12:07:58 -0700 (PDT) Date: Thu, 31 Mar 2022 15:07:58 -0400 From: Johannes Weiner To: Christoph Hellwig Cc: CGEL , axboe@kernel.dk, viro@zeniv.linux.org.uk, linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, akpm@linux-foundation.org, Yang Yang , Ran Xiaokai Subject: Re: [PATCH] block/psi: make PSI annotations of submit_bio only work for file pages Message-ID: References: <623938d1.1c69fb81.52716.030f@mx.google.com> <20220323061058.GA2343452@cgel.zte@gmail.com> <62441603.1c69fb81.4b06b.5a29@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Mar 30, 2022 at 10:15:32PM -0700, Christoph Hellwig wrote: > On Wed, Mar 30, 2022 at 12:17:09PM -0400, Johannes Weiner wrote: > > It's add_to_page_cache_lru() that sets the flag. > > > > Basically, when a PageWorkingset (hot) page gets reclaimed, the bit is > > stored in the vacated tree slot. When the entry is brought back in, > > add_to_page_cache_lru() transfers it to the newly allocated page. > > Ok. In this case my patch didn't quite do the right thing for readahead > either. But that does leave a question for the btrfs compressed > case, which only adds extra pages to a read to readahad a bigger > cluster size - that is these pages are not read at the request of the > VM. Does it really make sense to do PSI accounting for them in that > case? I think it does. I suppose it's an argument about readahead pages in general, which technically the workload itself doesn't commission explicitly. But those pages are still triggered by a nearby access, their reads contribute to device utilization, and if they're PageWorkingset it means they're only being read because there is a lack of memory. In a perfect world, readahead would stop when memory or IO are contended. But it doesn't, and the stalls it can inject into the workload are as real as stalls from directly requested reads.