linux-kernel - Re: [PATCH v2 0/2] mm: collect the number of anon mTHP

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAGsJ_4y30MVPDrE24okwxi5MYwM6o1ZnK0Vdub+DoEgWnM6+FQ@mail.gmail.com>
Date: Mon, 19 Aug 2024 20:52:35 +1200
From: Barry Song <21cnbao@...il.com>
To: David Hildenbrand <david@...hat.com>
Cc: akpm@...ux-foundation.org, linux-mm@...ck.org, 
	Usama Arif <usamaarif642@...il.com>, baolin.wang@...ux.alibaba.com, chrisl@...nel.org, 
	hanchuanhua@...o.com, ioworker0@...il.com, kaleshsingh@...gle.com, 
	kasong@...cent.com, linux-kernel@...r.kernel.org, ryan.roberts@....com, 
	v-songbaohua@...o.com, ziy@...dia.com, yuanshuai@...o.com
Subject: Re: [PATCH v2 0/2] mm: collect the number of anon mTHP

On Mon, Aug 19, 2024 at 8:33 PM Barry Song <21cnbao@...il.com> wrote:
>
> On Mon, Aug 19, 2024 at 8:28 PM David Hildenbrand <david@...hat.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.

>
> >
> > --
> > Cheers,
> >
> > David / dhildenb

Thanks
Barry