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: <87y13fqina.fsf@yhuang6-desk2.ccr.corp.intel.com>
Date: Thu, 26 Sep 2024 09:59:53 +0800
From: "Huang, Ying" <ying.huang@...el.com>
To: Nhat Pham <nphamcs@...il.com>
Cc: Baolin Wang <baolin.wang@...ux.alibaba.com>,  Yosry Ahmed
 <yosryahmed@...gle.com>,  akpm@...ux-foundation.org,  hannes@...xchg.org,
  hughd@...gle.com,  shakeel.butt@...ux.dev,  ryan.roberts@....com,
  chrisl@...nel.org,  david@...hat.com,  kasong@...cent.com,
  willy@...radead.org,  viro@...iv.linux.org.uk,  baohua@...nel.org,
  chengming.zhou@...ux.dev,  linux-mm@...ck.org,  kernel-team@...a.com,
  linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 0/2] remove SWAP_MAP_SHMEM

Nhat Pham <nphamcs@...il.com> writes:

> On Tue, Sep 24, 2024 at 6:53 PM Baolin Wang
> <baolin.wang@...ux.alibaba.com> wrote:
>>
>>
>> One benefit I can mention is that removing 'SWAP_MAP_SHMEM' can help to
>> batch free shmem swap entries in __swap_entries_free(), similar to the
>> commit bea67dcc5eea ("mm: attempt to batch free swap entries for
>> zap_pte_range()") did, which can improve the performance of shmem mTHP
>> munmap() function based on my testing.
>
> Yeah, the problem with having an extraneous state is you have to
> constantly check for it in code, and/or keep it in mind when you
> develop things. I've been constantly having to check for this state
> when I develop code around this area, and it gets old fast.
>
> If we can use it to optimize something, I can understand keeping it.
> But it just seems like dead code to me :)
>
> My preference is to do this as simply as possible - add another case
> (usage == 1, nr > 1, and we need to add swap continuations) in the
> check in __swap_duplicate()'s first loop, and just WARN right there.
>
> That case CANNOT happen UNLESS we introduce a bug, or have a new use
> case. When we actually have a use case, we can always introduce
> handling/fallback logic for that case.
>
> Barry, Yosry, Baolin, Ying, how do you feel about this?

Sounds good to me to just WARN now.  We can always improve when it's
necessary.

--
Best Regards,
Huang, Ying

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ