linux-kernel - Re: [PATCH v7 7/7] mm/madvise: allow KSM hints for remote API

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: <a63768c1-3959-563b-376b-1d8d90d79b41@suse.cz>
Date:   Fri, 6 Mar 2020 17:08:18 +0100
From:   Vlastimil Babka <vbabka@...e.cz>
To:     Oleksandr Natalenko <oleksandr@...hat.com>
Cc:     Minchan Kim <minchan@...nel.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        LKML <linux-kernel@...r.kernel.org>,
        linux-mm <linux-mm@...ck.org>, linux-api@...r.kernel.org,
        Suren Baghdasaryan <surenb@...gle.com>,
        Tim Murray <timmurray@...gle.com>,
        Daniel Colascione <dancol@...gle.com>,
        Sandeep Patil <sspatil@...gle.com>,
        Sonny Rao <sonnyrao@...gle.com>,
        Brian Geffon <bgeffon@...gle.com>,
        Michal Hocko <mhocko@...e.com>,
        Johannes Weiner <hannes@...xchg.org>,
        Shakeel Butt <shakeelb@...gle.com>,
        John Dias <joaodias@...gle.com>,
        Joel Fernandes <joel@...lfernandes.org>,
        Jann Horn <jannh@...gle.com>,
        alexander.h.duyck@...ux.intel.com, sj38.park@...il.com,
        SeongJae Park <sjpark@...zon.de>
Subject: Re: [PATCH v7 7/7] mm/madvise: allow KSM hints for remote API

On 3/6/20 2:41 PM, Oleksandr Natalenko wrote:
> On Fri, Mar 06, 2020 at 02:13:49PM +0100, Vlastimil Babka wrote:
>> On 3/2/20 8:36 PM, Minchan Kim wrote:
>> > From: Oleksandr Natalenko <oleksandr@...hat.com>
>> > 
>> > It all began with the fact that KSM works only on memory that is marked
>> > by madvise(). And the only way to get around that is to either:
>> > 
>> >   * use LD_PRELOAD; or
>> >   * patch the kernel with something like UKSM or PKSM.
>> > 
>> > (i skip ptrace can of worms here intentionally)
>> > 
>> > To overcome this restriction, lets employ a new remote madvise API. This
>> > can be used by some small userspace helper daemon that will do auto-KSM
>> > job for us.
>> > 
>> > I think of two major consumers of remote KSM hints:
>> > 
>> >   * hosts, that run containers, especially similar ones and especially in
>> >     a trusted environment, sharing the same runtime like Node.js;

Ah, I forgot to ask, given the discussion of races in patch 2 (Question 2),
where android can stop the tasks to apply the madvise hints in a race-free
manner, how does that work for remote KSM hints in your scenarios, especially
the one above?

>> > 
>> >   * heavy applications, that can be run in multiple instances, not
>> >     limited to opensource ones like Firefox, but also those that cannot be
>> >     modified since they are binary-only and, maybe, statically linked.
>> > 
>> > Speaking of statistics, more numbers can be found in the very first
>> > submission, that is related to this one [1]. For my current setup with
>> > two Firefox instances I get 100 to 200 MiB saved for the second instance
>> > depending on the amount of tabs.
>> > 
>> > 1 FF instance with 15 tabs:
>> > 
>> >    $ echo "$(cat /sys/kernel/mm/ksm/pages_sharing) * 4 / 1024" | bc
>> >    410
>> > 
>> > 2 FF instances, second one has 12 tabs (all the tabs are different):
>> > 
>> >    $ echo "$(cat /sys/kernel/mm/ksm/pages_sharing) * 4 / 1024" | bc
>> >    592
>> > 
>> > At the very moment I do not have specific numbers for containerised
>> > workload, but those should be comparable in case the containers share
>> > similar/same runtime.
>> > 
>> > [1] https://lore.kernel.org/patchwork/patch/1012142/
>> > 
>> > Reviewed-by: SeongJae Park <sjpark@...zon.de>
>> > Signed-off-by: Oleksandr Natalenko <oleksandr@...hat.com>
>> > Signed-off-by: Minchan Kim <minchan@...nel.org>
>> 
>> This will lead to one process calling unmerge_ksm_pages() of another. There's a
>> (signal_pending(current)) test there, should it check also the other task,
>> analogically to task 3?
> 
> Do we care about current there then? Shall we just pass mm into unmerge_ksm_pages and check the signals of the target task only, be it current or something else?

Dunno, it's nice to react to signals quickly, for any proces that gets them, no?

>> Then break_ksm() is fine as it is, as ksmd also calls it, right?
> 
> I think break_ksm() cares only about mmap_sem protection, so we should
> be fine here.
> 
>> 
>> > ---
>> >  mm/madvise.c | 4 ++++
>> >  1 file changed, 4 insertions(+)
>> > 
>> > diff --git a/mm/madvise.c b/mm/madvise.c
>> > index e77c6c1fad34..f4fa962ee74d 100644
>> > --- a/mm/madvise.c
>> > +++ b/mm/madvise.c
>> > @@ -1005,6 +1005,10 @@ process_madvise_behavior_valid(int behavior)
>> >  	switch (behavior) {
>> >  	case MADV_COLD:
>> >  	case MADV_PAGEOUT:
>> > +#ifdef CONFIG_KSM
>> > +	case MADV_MERGEABLE:
>> > +	case MADV_UNMERGEABLE:
>> > +#endif
>> >  		return true;
>> >  	default:
>> >  		return false;
>> > 
>> 
>