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] [day] [month] [year] [list]
Message-ID: <8d0a923115746ab77064764e391271403b5b820e.camel@surriel.com>
Date: Wed, 28 Aug 2024 08:54:23 -0400
From: Rik van Riel <riel@...riel.com>
To: "Kirill A . Shutemov" <kirill.shutemov@...ux.intel.com>
Cc: Johannes Weiner <hannes@...xchg.org>, Usama Arif
 <usamaarif642@...il.com>,  Nico Pache <npache@...hat.com>,
 linux-mm@...ck.org, linux-kernel@...r.kernel.org, 
 linux-doc@...r.kernel.org, Andrew Morton <akpm@...ux-foundation.org>, David
 Hildenbrand <david@...hat.com>, Matthew Wilcox <willy@...radead.org>, Barry
 Song <baohua@...nel.org>,  Ryan Roberts <ryan.roberts@....com>, Baolin Wang
 <baolin.wang@...ux.alibaba.com>, Lance Yang <ioworker0@...il.com>, Peter Xu
 <peterx@...hat.com>, Rafael Aquini <aquini@...hat.com>, Andrea Arcangeli
 <aarcange@...hat.com>, Jonathan Corbet <corbet@....net>, Zi Yan
 <ziy@...dia.com>
Subject: Re: [RFC 0/2] mm: introduce THP deferred setting

On Wed, 2024-08-28 at 09:17 +0300, Kirill A . Shutemov wrote:
> On Tue, Aug 27, 2024 at 09:18:58PM -0400, Rik van Riel wrote:
> > 
> > Workload owners are going to have a real problem trying to figure
> > out what the best value of max_ptes_none should be for their
> > workloads.
> > 
> > However, giving workload owners the ability to say "this workload
> > should not waste more than 1GB of memory on zero pages inside
> > THPs",
> > or 500MB, or 4GB or whatever, would then allow the kernel to
> > automatically adjust the max_ptes_none threshold.
> 
> The problem is that we don't have and cannot have the info on zero
> pages
> inside THPs readily available. It requires memory scanning which is
> prohibitively expensive if we want the info to be somewhat up-to-
> date.
> 
I'm not sure it needs to be super up to date.

After all, we only care when there is memory pressure, and
when there is memory pressure we will be doing some sort of
scanning, anyway.

With a shrinker in the mix, we do not need totally up to date
information, but can gradually approximate the target.

-- 
All Rights Reversed.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ