linux-kernel - Re: [PATCH v3 0/6] add mTHP support for anonymous shmem

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 for Android: free password hash cracker in your pocket

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

Message-ID: <5mezgqzg7wmd4iq2d2q3aentziosetwcll3tgdbl3mhriseyv3@pgxsux7qvxno>
Date: Tue, 4 Jun 2024 12:05:07 +0000
From: Daniel Gomez <da.gomez@...sung.com>
To: Baolin Wang <baolin.wang@...ux.alibaba.com>
CC: David Hildenbrand <david@...hat.com>, "akpm@...ux-foundation.org"
	<akpm@...ux-foundation.org>, "hughd@...gle.com" <hughd@...gle.com>,
	"willy@...radead.org" <willy@...radead.org>, "wangkefeng.wang@...wei.com"
	<wangkefeng.wang@...wei.com>, "ying.huang@...el.com" <ying.huang@...el.com>,
	"21cnbao@...il.com" <21cnbao@...il.com>, "ryan.roberts@....com"
	<ryan.roberts@....com>, "shy828301@...il.com" <shy828301@...il.com>,
	"ziy@...dia.com" <ziy@...dia.com>, "ioworker0@...il.com"
	<ioworker0@...il.com>, Pankaj Raghav <p.raghav@...sung.com>,
	"linux-mm@...ck.org" <linux-mm@...ck.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v3 0/6] add mTHP support for anonymous shmem

On Tue, Jun 04, 2024 at 05:45:20PM +0800, Baolin Wang wrote:
> 
> 
> On 2024/6/4 16:18, Daniel Gomez wrote:
> > On Fri, May 31, 2024 at 01:13:48PM +0200, David Hildenbrand wrote:
> > > > > 
> > > > > As a default, we should not be using large folios / mTHP for any shmem,
> > > > > just like we did with THP via shmem_enabled. This is what this series
> > > > > currently does, and is aprt of the whole mTHP user-space interface design.
> > > > > 
> > > > > Further, the mTHP controls should control all of shmem, not only
> > > > > "anonymous shmem".
> > > > 
> > > > Yes, that's what I thought and in my TODO list.
> > > 
> > > Good, it would be helpful to coordinate with Daniel and Pankaj.
> > 
> > I've integrated patches 11 and 12 from the lsf RFC thread [1] on top of Baolin's
> > v3 patches. You may find a version in my integration branch here [2]. I can
> > attach them here if it's preferred.
> > 
> > [1] https://lore.kernel.org/all/20240515055719.32577-1-da.gomez@samsung.com/
> > [2] https://protect2.fireeye.com/v1/url?k=a23e7c06-c3b56926-a23ff749-74fe485fb347-371ca2bfd5d9869f&q=1&e=6974304e-a786-4255-93a7-57498540241c&u=https%3A%2F%2Fgitlab.com%2Fdkruces%2Flinux-next%2F-%2Fcommits%2Fnext-20240604-shmem-mthp
> > 
> > The point here is to combine the large folios strategy I proposed with mTHP
> > user controls. Would it make sense to limit the orders to the mapping order
> > calculated based on the size and index?
> 
> IMO, for !anon shmem, this change makes sense to me. We should respect the
> size and mTHP should act as a order filter.

What about respecing the size when within_size flag is enabled? Then, 'always'
would allocate mTHP enabled folios, regardless of the size. And 'never'
would ignore mTHP and size. So, 'never' can be used for this 'safe' boot case
mentioned in the discussion.

> 
> For anon shmem, we should ignore the length, which you always set it to
> PAGE_SIZE in patch [1].
> 
> [1] https://protect2.fireeye.com/v1/url?k=0d75a0c6-6cfeb5e6-0d742b89-74fe485fb347-904fa75c8efebdc2&q=1&e=6974304e-a786-4255-93a7-57498540241c&u=https%3A%2F%2Fgitlab.com%2Fdkruces%2Flinux-next%2F-%2Fcommit%2Fedf02311fd6d86b355d3aeb74e67c8da6de3c569

Since we are ignoring the length, we should ignore any value being passed.

> 
> > @@ -1765,6 +1798,10 @@ static struct folio *shmem_alloc_and_add_folio(struct vm_fault *vmf,
> > 
> >                  order = highest_order(suitable_orders);
> >                  while (suitable_orders) {
> > +                       if (order > mapping_order) {
> > +                               order = next_order(&suitable_orders, order);
> > +                               continue;
> > +                       }
> >                          pages = 1UL << order;
> >                          index = round_down(index, pages);
> >                          folio = shmem_alloc_folio(gfp, order, info, index);
> > 
> > Note: The branch still need to be adapted to include !anon mm.