[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4fe0e2eb6a3e2d7e0838f177706f1be13d61375c.camel@surriel.com>
Date: Wed, 25 Jan 2023 13:43:09 -0500
From: Rik van Riel <riel@...riel.com>
To: Michal Hocko <mhocko@...e.com>,
David Hildenbrand <david@...hat.com>
Cc: Stefan Roesch <shr@...kernel.io>, linux-mm@...ck.org,
linux-doc@...r.kernel.org, linux-fsdevel@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-kselftest@...r.kernel.org,
linux-trace-kernel@...r.kernel.org, CGEL <cgel.zte@...il.com>,
Jann Horn <jannh@...gle.com>
Subject: Re: [RESEND RFC PATCH v1 00/20] mm: process/cgroup ksm support
On Wed, 2023-01-25 at 14:01 +0100, Michal Hocko wrote:
>
> I have read through your cover letter and it talks about the
> interface
> but it doesn't really talk about usecases and how they are supposed
> to
> use this feature - except the prctl based flag gets inherited. So
> could
> you elaborate some more about those usecases please?
I can explain a little about the use case. There are people
who use forked (rather than threaded) servers for certain
workloads, from a garbage collected language without pointers,
which means madvise simply cannot be made available in that
language.
The people running that workload have experimented with uKSM
in the past, and seen about a 20% capacity increase from
doing that.
Because madvise is not possible in that programming language,
and the addresses of data keep moving around as things get
garbage collected, KSM sharing needs to be enabled "from the
outside" for that workload.
prctl seems like a good way to do that.
--
All Rights Reversed.
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists