linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Usama Arif <usamaarif642@gmail.com>
To: Barry Song <21cnbao@gmail.com>,
	David Hildenbrand <david@redhat.com>,
	akpm@linux-foundation.org
Cc: linux-mm@kvack.org, baolin.wang@linux.alibaba.com,
	chrisl@kernel.org, hanchuanhua@oppo.com, ioworker0@gmail.com,
	kaleshsingh@google.com, kasong@tencent.com,
	linux-kernel@vger.kernel.org, ryan.roberts@arm.com,
	v-songbaohua@oppo.com, ziy@nvidia.com, yuanshuai@oppo.com
Subject: Re: [PATCH v2 0/2] mm: collect the number of anon mTHP
Date: Mon, 19 Aug 2024 10:22:44 -0400	[thread overview]
Message-ID: <b5f8448a-daf2-44d7-bcad-b66ff2908e63@gmail.com> (raw)
In-Reply-To: <CAGsJ_4y30MVPDrE24okwxi5MYwM6o1ZnK0Vdub+DoEgWnM6+FQ@mail.gmail.com>



On 19/08/2024 09:52, Barry Song wrote:
> On Mon, Aug 19, 2024 at 8:33 PM Barry Song <21cnbao@gmail.com> wrote:
>>
>> On Mon, Aug 19, 2024 at 8:28 PM David Hildenbrand <david@redhat.com> wrote:
>>>
>>> On 18.08.24 09:58, Barry Song wrote:
>>>> Hi Andrew, David, Usama,
>>>>
>>>> I'm attempting to rebase this series on top of Usama's
>>>> [PATCH v3 0/6] mm: split underutilized THPs[1]
>>>>
>>>> However, I feel it is impossible and we might be tackling things
>>>> in the wrong order.
>>>
>>> Is just the ordering suboptimal (which can/will get resolved one way or
>>> the other), or is there something fundamental that will make this series
>>> here "impossible"?
>>
>> i think it is just the ordering suboptimal. Ideally, mTHP counters can go
>> first, then the new partially_mapped feature will rebase on top of
>> mTHP counters.
> 
> Sorry, please allow me to ramble a bit more.
> 
> The nr_split_deferred counter is straightforward and simple without the
> partially_mapped feature. Each time we enter split_list, we increment by
> 1, and when we leave, we decrement by 1.
> 
> With the new partially_mapped feature, we can enter split_list without
> actually being partially_mapped. If the MTHP counter series is processed
> first, the partially_mapped series can handle all cases while properly
> clearing and setting the partially_mapped flag. These flag operations
> need to be handled carefully.
> Currently, I notice that Usama's series is clearing the flag unconditionally
> in all cases.
> 
> In simple terms, mTHP counters are just a counting mechanism that
> doesn't introduce new features. However, partially_mapped is a new
> feature. A better approach might be to handle the counters first, then
> ensure that the new feature doesn't break the counter.
> 

I am ok if the series needs to be reversed, I think the difficulty is for Andrew to tackle my series, yours and Yu Zhaos, which all seem to be touching the same code, so whatever makes it easier for Andrew I am happy with it.


>>
>>>
>>> --
>>> Cheers,
>>>
>>> David / dhildenb
> 
> Thanks
> Barry


      reply	other threads:[~2024-08-19 14:22 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-11 22:49 [PATCH v2 0/2] mm: collect the number of anon mTHP Barry Song
2024-08-11 22:49 ` [PATCH v2 1/2] mm: collect the number of anon large folios Barry Song
2024-08-21 21:34   ` David Hildenbrand
2024-08-22  0:52     ` Barry Song
2024-08-22  8:44       ` Barry Song
2024-08-22  8:59         ` David Hildenbrand
2024-08-22  9:21           ` Barry Song
2024-08-22 10:01             ` David Hildenbrand
2024-08-22 10:12               ` Barry Song
2024-08-11 22:49 ` [PATCH v2 2/2] mm: collect the number of anon large folios on split_deferred list Barry Song
2024-08-21 21:39   ` David Hildenbrand
2024-08-21 22:01     ` Barry Song
2024-08-21 22:10       ` David Hildenbrand
2024-08-18  7:58 ` [PATCH v2 0/2] mm: collect the number of anon mTHP Barry Song
2024-08-19  2:44   ` Usama Arif
2024-08-19  8:28   ` David Hildenbrand
2024-08-19  8:33     ` Barry Song
2024-08-19  8:52       ` Barry Song
2024-08-19 14:22         ` Usama Arif [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b5f8448a-daf2-44d7-bcad-b66ff2908e63@gmail.com \
    --to=usamaarif642@gmail.com \
    --cc=21cnbao@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=baolin.wang@linux.alibaba.com \
    --cc=chrisl@kernel.org \
    --cc=david@redhat.com \
    --cc=hanchuanhua@oppo.com \
    --cc=ioworker0@gmail.com \
    --cc=kaleshsingh@google.com \
    --cc=kasong@tencent.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=ryan.roberts@arm.com \
    --cc=v-songbaohua@oppo.com \
    --cc=yuanshuai@oppo.com \
    --cc=ziy@nvidia.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).