linux-kernel - Re: [RFC PATCH v1 0/5] Alternative mTHP swap allocator improvements

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: <878qz04ctk.fsf@yhuang6-desk2.ccr.corp.intel.com>
Date: Thu, 20 Jun 2024 09:34:15 +0800
From: "Huang, Ying" <ying.huang@...el.com>
To: Ryan Roberts <ryan.roberts@....com>
Cc: Andrew Morton <akpm@...ux-foundation.org>,  Chris Li
 <chrisl@...nel.org>,  Kairui Song <kasong@...cent.com>,  "Kalesh Singh"
 <kaleshsingh@...gle.com>,  Barry Song <baohua@...nel.org>,  Hugh Dickins
 <hughd@...gle.com>,  David Hildenbrand <david@...hat.com>,
  <linux-kernel@...r.kernel.org>,  <linux-mm@...ck.org>
Subject: Re: [RFC PATCH v1 0/5] Alternative mTHP swap allocator improvements

Ryan Roberts <ryan.roberts@....com> writes:

> On 19/06/2024 08:19, Huang, Ying wrote:
>> Hi, Ryan,
>> 
>> Ryan Roberts <ryan.roberts@....com> writes:
>> 
>>> Hi All,
>>>
>>> Chris has been doing great work at [1] to clean up my mess in the mTHP swap
>>> entry allocator.
>> 
>> I don't think the original behavior is something like mess.  It's just
>> the first step in the correct direction.  It's straightforward and
>> obviously correctly.  Then, we can optimize it step by step with data to
>> justify the increased complexity.
>
> OK, perhaps I was over-egging it by calling it a "mess". What you're describing
> was my initial opinion too, but I saw Andrew complaining that we shouldn't be
> merging a feature if it doesn't work.

I don't think it doesn't work.  It just works well for some workloads,
but doesn't work well for some other workloads.  We can always improve
the implementation to make it works better for more workloads.

>From another point of view, even with your and Chris's improvement, mTHP
swap entry allocation will fallback for quite some workloads.

Use page allocator as an example.  Even in current kernel, THP allocation
may fallback for quite some workloads because of page fragmentation.
But I don't think THP doesn't work now.

> This series fixes the problem in a minimal
> way - if you ignore the last patch, which is really is just a performance
> optimization and could be dropped.
>
> If we can ultimately get Chris's series to 0% fallback like this one, and
> everyone is happy with the current state for v6.10, then agreed - let's
> concentrate on Chris's series for v6.11.

[snip]

--
Best Regards,
Huang, Ying