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 B3C6AD1BDF2 for ; Mon, 4 Nov 2024 21:24:08 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3071F6B009C; Mon, 4 Nov 2024 16:24:08 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 2B7996B00A0; Mon, 4 Nov 2024 16:24:08 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 17EF26B00A1; Mon, 4 Nov 2024 16:24:08 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id E74346B009C for ; Mon, 4 Nov 2024 16:24:07 -0500 (EST) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 92CD4120B04 for ; Mon, 4 Nov 2024 21:24:07 +0000 (UTC) X-FDA: 82749689526.21.B12877F Received: from mail-wm1-f49.google.com (mail-wm1-f49.google.com [209.85.128.49]) by imf27.hostedemail.com (Postfix) with ESMTP id 7E84A4000B for ; Mon, 4 Nov 2024 21:23:32 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=hMCfbrxF; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf27.hostedemail.com: domain of usamaarif642@gmail.com designates 209.85.128.49 as permitted sender) smtp.mailfrom=usamaarif642@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1730755387; a=rsa-sha256; cv=none; b=Uqf9VB+sHDjmj1vRSGoTSLo1XkyAFslSxhVnO3IlYc/pvYMzDpkgMmy2lZUBzJGWat4A6J nJFr/mIRkieeTcT7Wn+X5YXKwpVtk8isF6O9uWBDEhIgfuum758TRVaej/XHzV1MdKXYvX EyWIGSJHP/hsT6h4+heLS2dO5a3OTm8= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=hMCfbrxF; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf27.hostedemail.com: domain of usamaarif642@gmail.com designates 209.85.128.49 as permitted sender) smtp.mailfrom=usamaarif642@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1730755387; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=o/2yu7UvclEjFD80MpaPkf/0nw6X3u5y/74H0s6nPtE=; b=erRLOKNRYYBHXGxMgI52B+aIgwF2VswDp7iuoG8X7eJfY7wpei2xyjdHzjnUPolfSZYcvU vhWx8LxiixST7ABU6OgL85IqG9Ha4ZSDWGrvjvyjXwpyfbdBwUlBcNgci7ZuIGPUDU7iHX pjuQk6mXddwwf2M/xAf9nto+keKalPI= Received: by mail-wm1-f49.google.com with SMTP id 5b1f17b1804b1-43162cf1eaaso56517605e9.0 for ; Mon, 04 Nov 2024 13:24:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1730755444; x=1731360244; darn=kvack.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=o/2yu7UvclEjFD80MpaPkf/0nw6X3u5y/74H0s6nPtE=; b=hMCfbrxFb+oaOttncXPEjvvkJADpXFoKmoqIU4dgWy6zpHDCteDc1dlM27ZXd+vRSn iALZ1av3eLDezdrLxRRhWMwDU0effVPhv8G9cPe3NLBoZIGlKcI+6krV9SkhhkYnHvTX xcXh3pIXbCBKk9Fus6hLJSInerNq0y+B5HNUR3zXhTXsAu7FmOMYiKJsmcFK77pRirYk 2HA2DTiwKeTZREOImRQaL7NbACASxNT29VOtVALV9FBLEL8KsHV3FcfWeqZZijorfzed ded5Ukk0xqJFTzkdfWuPjcxitbMDaicTZIFnxwjmDH+3nbaEO/yyVkPhrQx7K4LFxlt+ 0beQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1730755444; x=1731360244; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=o/2yu7UvclEjFD80MpaPkf/0nw6X3u5y/74H0s6nPtE=; b=Sm9/zq0PQ2K20v6zUiSlu2QjZHaM/GrEI/sD67qgNCdy6TS+LduwX7t+taX4q+R8Gt JfadeTkPpJSmu246WTmf8RG2jBZfnNhAKcVFsgX2Ftiegbvf4zzkHyvlQkBQKCfVmP61 VmL8MblEZp0SmFCVsTtNFpwN2Vw0YoPGWBocP7ToO/iSeXVerVGHdIr5S1ioPX/a3C8e keLuPKMsTO7df52W+RfSyDVBusShXnIrm/raS163seZtCsK6QF8rLma/5/hCWwLCFoeh aXnU3Bzv+pDM4Io9bB0Nt5e05JT/iRKajTLflFJkPjG6Ahz98qqKBc6v5xeCsQR84g8E MK8A== X-Forwarded-Encrypted: i=1; AJvYcCU7e4EmZ3qAWSKvA9EnKXx3C8Np/6CJtqTYi+XeWWRy0g3YzY6npgNnH6maZU7SgYFE/etTI996Mg==@kvack.org X-Gm-Message-State: AOJu0Yw8KwnAYSZZosJIK8EK95ySiR8fUSF/hdXfOYO83cy3ZlFdkuln s5sXyilD5mJzjSM3C+v+AAlJiQqfnizfem8dSLZKcZDImZRaCDsmw/VbNg== X-Google-Smtp-Source: AGHT+IEtoXGebHuHOKWu8sWKvgbachVIM1d0ifzwpPlcjVESbb9RWPN7ltg5rPUimEiiVmwZDqQ9Ug== X-Received: by 2002:a5d:5847:0:b0:37d:4619:f975 with SMTP id ffacd0b85a97d-381c7a5d351mr16267861f8f.19.1730755443715; Mon, 04 Nov 2024 13:24:03 -0800 (PST) Received: from ?IPV6:2a02:6b67:d751:7400:c2b:f323:d172:e42a? ([2a02:6b67:d751:7400:c2b:f323:d172:e42a]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-381c10d40casm14211218f8f.27.2024.11.04.13.24.03 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 04 Nov 2024 13:24:03 -0800 (PST) Message-ID: <79deed1a-9b0e-42e0-be2f-f0c3ef5fee11@gmail.com> Date: Mon, 4 Nov 2024 21:24:02 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] mm: count zeromap read and set for swapout and swapin To: David Hildenbrand , Johannes Weiner Cc: Barry Song <21cnbao@gmail.com>, akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Barry Song , Chengming Zhou , Yosry Ahmed , Nhat Pham , Hugh Dickins , Matthew Wilcox , Shakeel Butt , Andi Kleen , Baolin Wang , Chris Li , "Huang, Ying" , Kairui Song , Ryan Roberts , joshua.hahnjy@gmail.com References: <20241102101240.35072-1-21cnbao@gmail.com> <20241104163402.GA810664@cmpxchg.org> <3ac28c1a-44d4-4b10-966e-0907df716da0@gmail.com> <410abcf1-d43c-4368-b217-4ff894903440@redhat.com> Content-Language: en-US From: Usama Arif In-Reply-To: <410abcf1-d43c-4368-b217-4ff894903440@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspam-User: X-Rspamd-Queue-Id: 7E84A4000B X-Rspamd-Server: rspam01 X-Stat-Signature: 88hngi4rx8wk3piqqujthjo6xs7h7gcs X-HE-Tag: 1730755412-827733 X-HE-Meta: U2FsdGVkX1/fw5Mu2xKZNrNzAcPuz+obTq1exT3PgP4h0w+RiMgKz8m5ZMq3qKDsTb10QLFTQ1S7NJTLpYm9Nl+0F87RWMbLkQIwgHP+nySzsZrudN2lchFLhDXI+bLvwl91O2QeveYFZc5krlpPQUBJ73xj6BdyjGdCgPcAM13ioVu9svaqYn4WYF/oVYW3X4p/WtlawIx9DaKT9aUTO3cNK04XcudqM6nO889EGBCu6C1soPPsV3TdslAtgJ3508msKFO0zU0CYCXeqCvrauccOhSZ2DqIzcAzaBAAgmGExooNEQSQAmT0jAGeSFNXw64cP4RHci6dX7UtvjlxkOBgZ2ptwUu2NmTePmaKdjhzIHKt1dw69f65iEr25cTMX1/bypLpWZD9YJKv+udnDh2reJac/V8b4JdPdd9pNB7U+8nAIlreuKduWOHKgSkCC+hoerd0IvH0Rw7g+02l1bGkWAtbsySvVl59zejNr7ZPGkpD8Vl0oM0VKAG9VDaKckujwr65135Adwcw2E+WSfGmCIoPBptL+1HsltDluLt+bP4whA8g+2ydBXLxffx7qq821T6/eNu1wH6o7Lpaw39KgEGs4ojjRZFUp/GmH4VaHHTGo3RBjOxEFAQ8ARajREunYOX5CY5g+e/kktGk9yJSeD0tnN2xiBn9Tlp9nRxRzaUHwLwPAxqJa0ylnDP05WQwLycO3ms64/lvAAL+gYCDIzbXDy+w79HG7gp1WdqtDPkx9QHX5D6JrFv+v75hcimikWw4yedaxXc6BzxO+PkKAMptfSutRgjugy9TJ4OgEiHr9WvuL1Tns0IIqwXu2OzQnXZqb6a4wRelver6oLRErXit7Bz99MJ6vJCxRyXXjzdM6FPJMD1Gk0PuyA+Giia7aXwR9ULKP8+KMJ7PnfCeLabCzS7v0iakGnskGeViNR0Ocdy+PnoXxLbtpEbbE/3UGVS3g9fI88sXFai xBvXbyq2 jwBJVaWJ07o3xAoCRPz61SueIuf6XHA6j3fFD6EdD6iUlUK+ajfAe6n5MYguMGylnP6or7Kx8htxujWM+oGZwLRYfkqixEUGOuhNJnygLN4LnohS+opDEPLWPZTPsp8B+cvyx9HBh/GTUhEOPj+4Xrw/MU4TsBzF01KvF3Ld0eK21Hm857vGPsY+DTqUkwk8SQAcs9VRE9AheIqVeQHY13ApwAjfK34c2hajmnRB1iAf+8UDVcHoYNNrpZmMdmZHJ0S+EK4NnFP1c+AUippKeFJQpBkG/tUJwrnaONSeC1Tv8BOylxS7R7vyuVC6qate3gDDBba9FJa2Ul9b6BHAd6tUJkktfHE636yj+P/jEep1cbeG3UelNvWZN1jMwok4oyZe9KaSu27cLDbXzesjpHTzJUPvXMr0tR5R3dHqZbENi978/kBSuPMZ8NbLxj6zJKBOUBehNkbGExvVEr3AXcBPx7wHtQFjpr8MOIkVQir+QidP+kvrkw+ttWFqcKn9e4LHG2v9qMrSJIS8XR5h4s6A6/g== 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 04/11/2024 20:56, David Hildenbrand wrote: > On 04.11.24 19:48, Usama Arif wrote: >> >> >> On 04/11/2024 17:10, David Hildenbrand wrote: >>> On 04.11.24 17:34, Johannes Weiner wrote: >>>> On Mon, Nov 04, 2024 at 01:42:08PM +0100, David Hildenbrand wrote: >>>>> On 02.11.24 11:12, Barry Song wrote: >>>>>> @@ -1599,6 +1599,16 @@ The following nested keys are defined. >>>>>>           pglazyfreed (npn) >>>>>>             Amount of reclaimed lazyfree pages >>>>>>     +      swpin_zero >>>>>> +        Number of pages moved into memory with zero content, meaning no >>>>>> +        copy exists in the backend swapfile, allowing swap-in to avoid >>>>>> +        I/O read overhead. >>>>>> + >>>>>> +      swpout_zero >>>>>> +        Number of pages moved out of memory with zero content, meaning no >>>>>> +        copy is needed in the backend swapfile, allowing swap-out to avoid >>>>>> +        I/O write overhead. >>>>> >>>>> Hm, can make it a bit clearer that this is a pure optimization and refer >>>>> to the other counters? >>>>> >>>>> swpin_zero >>>>>      Portion of "pswpin" pages for which I/O was optimized out >>>>>      because the page content was detected to be zero during swapout. >>>> >>>> AFAICS the zeropages currently don't show up in pswpin/pswpout, so >>>> these are independent counters, not subsets. >>> >>> Ah. now I understand the problem. The whole "move out of memory" "move into memory" here is quite confusing TBH. We're not moving anything, we're optimizing out the move completely ... yes, you could call it compression (below). >>> >>>> >>>> I'm leaning towards Barry's side on the fixes tag. >>> >>> I think the documentation when to use the Fixes: tag is pretty clear. >>> >>> Introducing new counters can hardly be considered a bugfix. Missing to adjust some counters that *existing tools* would know/use might be  IMO (below). >>> >>>>   When zswap handled >>>> the same-filled pages, we would count them in zswpin/out. From a user >>>> POV, especially one using zswap, the behavior didn't change, but the >>>> counts giving insight into this (potentially significant) VM activity >>>> disappeared. This is arguably a regression. >>>>>> swpout_zero >>>>>      Portion of "pswout" pages for which I/O was optimized out >>>>>      because the page content was detected to be zero. >>>> >>>> Are we sure we want to commit to the "zero" in the name here? Until >>>> very recently, zswap optimized all same-filled pages. It's possible >>>> somebody might want to bring that back down the line. >>> >>> Agreed. >>> >>>> >>>> In reference to the above, I'd actually prefer putting them back into >>>> zswpin/zswpout. Sure, they're not handled by zswap.c proper, but this >>>> is arguably just an implementation detail; from a user POV this is >>>> still just (a form of) compression in lieu of IO to the swap backend. >>>> >>>> IMO there is no need for coming up with a separate category. Just add >>>> them to zswpin/zswpout and remove the CONFIG_ZSWAP guards from them? >>> >> >> hmm, I actually don't like the idea of using zswpin/zswpout. Its a >> bit confusing if zswap is disabled and zswap counters are incrementing? >> >> Also, it means that when zswap is enabled, you won't be able to distinguish >> between zswap and zeropage optimization. > > Does it matter? Because in the past the same would have happened, no (back when this was done in zswap code)? > When it was in zswap code, there was zswap_same_filled_pages stat as well to see how many zero-filled pages were part of zswap. (Not the same as counter, but you could still get a good idea about same filled page usage). The other thing is it affects zram as well.. Maybe We could have a hybrid approach? i.e. have the zswpin/zswpout counter incremented at zero filled pages as suggested, but then also have a zero_swapped stat that tells how much of the zeromap is currently set (similar to zswapped).