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 A422FC433EF for ; Fri, 3 Dec 2021 09:17:29 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 137C06B0072; Fri, 3 Dec 2021 04:17:19 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 0E8A16B0074; Fri, 3 Dec 2021 04:17:19 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EF34D6B0075; Fri, 3 Dec 2021 04:17:18 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0104.hostedemail.com [216.40.44.104]) by kanga.kvack.org (Postfix) with ESMTP id E079B6B0072 for ; Fri, 3 Dec 2021 04:17:18 -0500 (EST) Received: from smtpin03.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id A76BF88487 for ; Fri, 3 Dec 2021 09:17:08 +0000 (UTC) X-FDA: 78875928936.03.D77C347 Received: from mail-qk1-f177.google.com (mail-qk1-f177.google.com [209.85.222.177]) by imf18.hostedemail.com (Postfix) with ESMTP id 59CFE4002087 for ; Fri, 3 Dec 2021 09:17:08 +0000 (UTC) Received: by mail-qk1-f177.google.com with SMTP id 132so2711177qkj.11 for ; Fri, 03 Dec 2021 01:17:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jgvMwOkDcRoUF6R7PGhUdw3mIh9JYIpn/aXxn0rHolQ=; b=nWccPpijhFPpxe62l6g043xtvIKpN4xKMVs4CaZGS92+m9gNBa5P1/seNwuuKz157r avZG6v5LcPlAzEJiEEA7NvXEvb8qQCsX2PW/YApleUrHn4/t5BfILeIa10oQquZQaGhI VEVXb0YgWQc+VF36v6V5CpTczgIXpdBrJVYBDqLQWly8Z9foXAfUsQ5NF3A8QbhFjoLd GHNWpXwBq5pKeZrC1DmEnDziTeUzcS58/62urVJOSdciDK8w0Jj9D3YQOtdLWaZjb2KS JQl1ONfgjwIW1E8YCufzPstnfeNSv6XJfOwQ2zLSHdjq6A+HEDVY5yI5q6sWmk2W2ZAe gHbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jgvMwOkDcRoUF6R7PGhUdw3mIh9JYIpn/aXxn0rHolQ=; b=NrjhsDRWl7apL7VU28FOjtYpw1GG5gCilIiR2lP2zCe7X7V6eCZ2hqjsWuxLmSAG1E vK4jIdLw1E+ZyFhzMYaUyPrMm9TRhdhXL6i1C6/v8MyaANHVMHCdadsS6588Nu0AxoTJ S+L/KVm7ETs+DbbsqLPJ3WWYuDmo4wva71vfyu8CZ2nVEpWGJC8wYzy/rrNhABjEXiuw gmXfdBX7nNhkZohfj+6BT5iusuXAyVffl4vLsNSxxWWSlgV/hcQZcBVGwSCudqNTZJXU aLC1bPgoR9N3doZHm5QUxd73hFTA116h3T3/bmTOMVBD7JEnIN4y54dYiNv8X5rk4Cvt u8Og== X-Gm-Message-State: AOAM533wZOWD0TZxTXBjSakpkFsJB2CqDK3lUMwoygCYf/OazCFto9mi 8onZ0XuxR5X/GCU6WTp07hXcCvng3riY0vQH5jA= X-Google-Smtp-Source: ABdhPJxAFBqQY6PWlnykAzmKxVmXsxvG6coacu8lAxuXBr0Kgrlh2Jfe1aY7MuMC1/QFtZH//XO0uIVKWVWUuYCDcaI= X-Received: by 2002:a05:620a:2989:: with SMTP id r9mr16108300qkp.630.1638523027682; Fri, 03 Dec 2021 01:17:07 -0800 (PST) MIME-Version: 1.0 References: <1638356341-17014-1-git-send-email-huangzhaoyang@gmail.com> In-Reply-To: From: Zhaoyang Huang Date: Fri, 3 Dec 2021 17:16:47 +0800 Message-ID: Subject: Re: [RFC PATCH] mm: count zram read/write into PSI_IO_WAIT To: Johannes Weiner Cc: Nitin Gupta , Sergey Senozhatsky , Jens Axboe , Minchan Kim , Zhaoyang Huang , "open list:MEMORY MANAGEMENT" , LKML Content-Type: text/plain; charset="UTF-8" Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=nWccPpij; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf18.hostedemail.com: domain of huangzhaoyang@gmail.com designates 209.85.222.177 as permitted sender) smtp.mailfrom=huangzhaoyang@gmail.com X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 59CFE4002087 X-Stat-Signature: s318f14at5ftqhfjnjmm1uwgwur485cy X-HE-Tag: 1638523028-182407 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 Fri, Dec 3, 2021 at 12:28 AM Johannes Weiner wrote: > > On Wed, Dec 01, 2021 at 07:12:30PM +0800, Zhaoyang Huang wrote: > > There is no chance for zram reading/writing to be counted in > > PSI_IO_WAIT so far as zram will deal with the request just in current > > context without invoking submit_bio and io_schedule. > > Hm, but you're also not waiting for a real io device - during which > the CPU could be doing something else e.g. You're waiting for > decompression. The thread also isn't in D-state during that time. What > scenario would benefit from this accounting? How is IO pressure from > comp/decomp paths actionable to you? No. Block device related D-state will be counted in via psi_dequeue(io_wait). What I am proposing here is do NOT ignore the influence on non-productive time by huge numbers of in-context swap in/out (zram like). This can help to make IO pressure more accurate and coordinate with the number of PSWPIN/OUT. It is like counting the IO time within filemap_fault->wait_on_page_bit_common into psi_mem_stall, which introduces memory pressure high by IO. > > What about when you use zram with disk writeback enabled, and you see > a mix of decompression and actual disk IO. Wouldn't you want to be > able to tell the two apart, to see if you're short on CPU or short on > IO bandwidth in this setup? Your patch would make that impossible. OK. Is it better to start the IO counting from pageout? Both of the bdev and ram backed swap would benefit from it. > > This needs a much more comprehensive changelog. > > > > @@ -1246,7 +1247,9 @@ static int __zram_bvec_read(struct zram *zram, struct page *page, u32 index, > > > zram_get_element(zram, index), > > > bio, partial_io); > > > } > > > - > > > +#ifdef CONFIG_PSI > > > + psi_task_change(current, 0, TSK_IOWAIT); > > > +#endif > > Add psi_iostall_enter() and leave helpers that encapsulate the ifdefs. OK.