From: Rik van Riel <riel@surriel.com>
To: Matthew Wilcox <willy@infradead.org>, Stefan Roesch <shr@devkernel.io>
Cc: kernel-team@fb.com, linux-mm@kvack.org, mhocko@suse.com,
david@redhat.com, linux-kselftest@vger.kernel.org,
linux-doc@vger.kernel.org, akpm@linux-foundation.org
Subject: Re: [RFC PATCH v2 00/19] mm: process/cgroup ksm support
Date: Fri, 10 Feb 2023 21:41:19 -0500 [thread overview]
Message-ID: <4cc446385c79fb04e092a038f82cabc059afa4b0.camel@surriel.com> (raw)
In-Reply-To: <Y+bR99Ca+7SObeQo@casper.infradead.org>
[-- Attachment #1: Type: text/plain, Size: 1231 bytes --]
On Fri, 2023-02-10 at 23:23 +0000, Matthew Wilcox wrote:
> On Fri, Feb 10, 2023 at 01:50:04PM -0800, Stefan Roesch wrote:
> > So far KSM can only be enabled by calling madvise for memory
> > regions. What is
> > required to enable KSM for more workloads is to enable / disable it
> > at the
> > process / cgroup level.
> >
> > Use case:
> > The madvise call is not available in the programming language. An
> > example for
> > this are programs with forked workloads using a garbage collected
> > language without
> > pointers. In such a language madvise cannot be made available.
> >
> > In addition the addresses of objects get moved around as they are
> > garbage
> > collected. KSM sharing needs to be enabled "from the outside" for
> > these type of
> > workloads.
>
> Don't you have source code to the interpreter for this mysterious
> language? Usually that would be where we put calls to madvise()
That same interpreter is also used for workloads where
KSM brings no benefit, and we don't want the overhead
of KSM.
It really would be useful to have the ability to enable
this on a per workload basis, for programming languages
that do not support madvise.
--
All Rights Reversed.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2023-02-11 2:42 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-10 21:50 [RFC PATCH v2 00/19] mm: process/cgroup ksm support Stefan Roesch
2023-02-10 21:50 ` [RFC PATCH v2 01/19] mm: add new flag to enable ksm per process Stefan Roesch
2023-02-10 21:50 ` [RFC PATCH v2 02/19] mm: add flag to __ksm_enter Stefan Roesch
2023-02-10 21:50 ` [RFC PATCH v2 03/19] mm: add flag to __ksm_exit call Stefan Roesch
2023-02-10 21:50 ` [RFC PATCH v2 04/19] mm: invoke madvise for all vmas in scan_get_next_rmap_item Stefan Roesch
2023-02-10 21:50 ` [RFC PATCH v2 05/19] mm: support disabling of ksm for a process Stefan Roesch
2023-02-10 21:50 ` [RFC PATCH v2 06/19] mm: add new prctl option to get and set " Stefan Roesch
2023-02-10 21:50 ` [RFC PATCH v2 07/19] mm: split off pages_volatile function Stefan Roesch
2023-02-10 21:50 ` [RFC PATCH v2 08/19] mm: expose general_profit metric Stefan Roesch
2023-02-10 21:50 ` [RFC PATCH v2 09/19] docs: document general_profit sysfs knob Stefan Roesch
2023-02-11 8:17 ` Bagas Sanjaya
2023-02-15 23:00 ` Stefan Roesch
2023-02-10 21:50 ` [RFC PATCH v2 10/19] mm: calculate ksm process profit metric Stefan Roesch
2023-02-10 21:50 ` [RFC PATCH v2 11/19] mm: add ksm_merge_type() function Stefan Roesch
2023-02-10 21:50 ` [RFC PATCH v2 12/19] mm: expose ksm process profit metric in ksm_stat Stefan Roesch
2023-02-10 21:50 ` [RFC PATCH v2 13/19] mm: expose ksm merge type " Stefan Roesch
2023-02-10 21:50 ` [RFC PATCH v2 14/19] docs: document new procfs ksm knobs Stefan Roesch
2023-02-11 8:18 ` Bagas Sanjaya
2023-02-10 21:50 ` [RFC PATCH v2 15/19] tools: add new prctl flags to prctl in tools dir Stefan Roesch
2023-02-10 21:50 ` [RFC PATCH v2 16/19] selftests/vm: add KSM prctl merge test Stefan Roesch
2023-02-10 21:50 ` [RFC PATCH v2 17/19] selftests/vm: add KSM get merge type test Stefan Roesch
2023-02-10 21:50 ` [RFC PATCH v2 18/19] selftests/vm: add KSM fork test Stefan Roesch
2023-02-10 21:50 ` [RFC PATCH v2 19/19] selftests/vm: add two functions for debugging merge outcome Stefan Roesch
2023-02-10 23:23 ` [RFC PATCH v2 00/19] mm: process/cgroup ksm support Matthew Wilcox
2023-02-11 2:41 ` Rik van Riel [this message]
2023-02-21 16:10 ` Johannes Weiner
2023-02-21 17:59 ` Stefan Roesch
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4cc446385c79fb04e092a038f82cabc059afa4b0.camel@surriel.com \
--to=riel@surriel.com \
--cc=akpm@linux-foundation.org \
--cc=david@redhat.com \
--cc=kernel-team@fb.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--cc=shr@devkernel.io \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).