[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6303e3c9-85d5-40f5-b265-70ecdb02d5ba@gmail.com>
Date: Mon, 28 Oct 2024 17:00:36 +0000
From: Usama Arif <usamaarif642@...il.com>
To: Nhat Pham <nphamcs@...il.com>
Cc: Barry Song <21cnbao@...il.com>, akpm@...ux-foundation.org,
linux-mm@...ck.org, linux-kernel@...r.kernel.org,
Barry Song <v-songbaohua@...o.com>, Chengming Zhou
<chengming.zhou@...ux.dev>, Yosry Ahmed <yosryahmed@...gle.com>,
Johannes Weiner <hannes@...xchg.org>, David Hildenbrand <david@...hat.com>,
Hugh Dickins <hughd@...gle.com>, Matthew Wilcox <willy@...radead.org>,
Shakeel Butt <shakeel.butt@...ux.dev>, Andi Kleen <ak@...ux.intel.com>,
Baolin Wang <baolin.wang@...ux.alibaba.com>, Chris Li <chrisl@...nel.org>,
"Huang, Ying" <ying.huang@...el.com>, Kairui Song <kasong@...cent.com>,
Ryan Roberts <ryan.roberts@....com>, joshua.hahnjy@...il.com
Subject: Re: [PATCH RFC] mm: count zeromap read and set for swapout and swapin
On 28/10/2024 16:33, Nhat Pham wrote:
> On Mon, Oct 28, 2024 at 5:23 AM Usama Arif <usamaarif642@...il.com> wrote:
>>
>> I wonder if instead of having counters, it might be better to keep track
>> of the number of zeropages currently stored in zeromap, similar to how
>> zswap_same_filled_pages did it. It will be more complicated then this
>> patch, but would give more insight of the current state of the system.
>>
>> Joshua (in CC) was going to have a look at that.
>
> I don't think one can substitute for the other.
Yes agreed, they have separate uses and provide different information, but
maybe wasteful to have both types of counters? They are counters so maybe
dont consume too much resources but I think we should still think about
it..
If you think from a production context, I feel like the number of pages
currently in zeromap could be more useful than just accumulation of all
zeromap loads/stores, which after days is just going to be a very large
number. You can compare the accumulations at different points in time,
but they dont take into account freeing swap slots and swap_reclaim.
If we are open to having both types then its ok. But might be good to
have that discussion here.
>
> The "current zeromapped page" counter gives you a breakdown of where
> memory resides, whereas the in/out counters explain past performance
> based on events that have happened. That's why you have zswap,
> zswapped, zswpout, zswpin.
Powered by blists - more mailing lists