Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp217310yba; Tue, 14 May 2019 23:27:09 -0700 (PDT) X-Google-Smtp-Source: APXvYqxDKdhANfDpnvzYwF178YZtYOcUxSfgN0MfrzKHTjqsWeklCKkQerYVwvZvUQr5q2KEooXk X-Received: by 2002:a17:902:7406:: with SMTP id g6mr40731644pll.328.1557901629192; Tue, 14 May 2019 23:27:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1557901629; cv=none; d=google.com; s=arc-20160816; b=YwhKWjaKR1JapkloxkTzRAkZRHta8UhAh7mw75dsZrhH/MMpdantmPklB4VSIMj2Wm MRflPymmQkOj07ggBOpeEB7X3V006yo1SE3s5ngWgNPSa0q3Fdh4WgOGtSyW+ySNTBbk Mb6kbGw0GkM6ryNc4bHFgFn7T3aVG9+9LUwYKwrGnGqihXE+ZfffOr32wDBHwrXI7Rad MAXzvAE7FmbQ1ktz8VwYsoLo6VcBUnamqi26xkfI9ztjXjEdOqebxzxY50uXoMhxyt0G uGY/nI64f3An66Gid1kvajzkjgs2jpQuu4hXVilWCTZ+1AOBiRKJmrVhdVeQpNDoc+lS c0YA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=uH/Ak+qwpv4XA3p578BfJ9QI58tlfVBtU336J8yg4yM=; b=Rhq2dk9puqhSue77Nq/F18drF8xiPnew+SfrhXfrxAzkTJHCUC1Rx/uGD5p1FgbE12 TIXoUaqWln580uVXO5rjjHVCiRwllVKGY1asVcJfZDKyZWhjeVHWRfdnk11blw6/naD6 YJUzyZIBwdIM7H9y22WSGZlDHrbFidQ3VO57kuxv5DGfrz0Or2MQ3PbXhiQc9wohRfES dp9f/tB19lk2Il/Ev0VbBLHK84B6H3G/14YtT02B5B+igUhqLtP15+Y+VS86cJIDijpY qMOJpSfe/0wjj3HX2c7S7CRO1Lq3PB08D1oO5sfoYh8Tf4l+8f6n8hZpobCDP6GOWHRi 9SEg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a27si1312788pfr.186.2019.05.14.23.26.53; Tue, 14 May 2019 23:27:09 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726146AbfEOGZ2 (ORCPT + 99 others); Wed, 15 May 2019 02:25:28 -0400 Received: from mail-wr1-f65.google.com ([209.85.221.65]:42239 "EHLO mail-wr1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725877AbfEOGZ1 (ORCPT ); Wed, 15 May 2019 02:25:27 -0400 Received: by mail-wr1-f65.google.com with SMTP id l2so1202274wrb.9 for ; Tue, 14 May 2019 23:25:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=uH/Ak+qwpv4XA3p578BfJ9QI58tlfVBtU336J8yg4yM=; b=iEEcxP+OkrJbOak0/0b7pjbRSGQWiUJCO+nFb6hZcKDiaWAQMFLAlFaKNYasT5ISsZ FGSkEfm/YSso6zyRo2DLmwzd6kY20JCguee+yCVoemgbi1OVVagm5HX0BvFnGKGEmxzu o/ilO+F1r0rS47cAHSZSI9l8kovMaYAt95AM/xXfdnEhn2zsedQghp+pL+UyiYKeySUC NWTxPIWH1NAphs0ZCuDVOcYPv5b1uEEyxESI6+tLeO7Gx5Qi0uUa6oQl93xBJe2wYiTp UeOqxVEIfLiputoYiawLVjfpBmaT6VwouZpxv5VhHFC+QaQuU+r7uliqF36Tvis9hl0H ukoQ== X-Gm-Message-State: APjAAAV1den7NtV45qgsaCrBjJnhX4BXlqP6tJ1rMJpEHU1ibbO2UhMU QJy62Y4tnyDIZngZr0bwqIw2vQ== X-Received: by 2002:adf:b6a5:: with SMTP id j37mr20768030wre.4.1557901525798; Tue, 14 May 2019 23:25:25 -0700 (PDT) Received: from localhost (nat-pool-brq-t.redhat.com. [213.175.37.10]) by smtp.gmail.com with ESMTPSA id o6sm1390076wrh.55.2019.05.14.23.25.24 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 14 May 2019 23:25:25 -0700 (PDT) Date: Wed, 15 May 2019 08:25:23 +0200 From: Oleksandr Natalenko To: Michal Hocko Cc: linux-kernel@vger.kernel.org, Kirill Tkhai , Vlastimil Babka , Matthew Wilcox , Pavel Tatashin , Timofey Titovets , Aaron Tomlin , Grzegorz Halat , linux-mm@kvack.org, linux-api@vger.kernel.org, Hugh Dickins Subject: Re: [PATCH RFC v2 0/4] mm/ksm: add option to automerge VMAs Message-ID: <20190515062523.5ndf7obzfgugilfs@butterfly.localdomain> References: <20190514131654.25463-1-oleksandr@redhat.com> <20190514144105.GF4683@dhcp22.suse.cz> <20190514145122.GG4683@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190514145122.GG4683@dhcp22.suse.cz> User-Agent: NeoMutt/20180716 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi. On Tue, May 14, 2019 at 04:51:22PM +0200, Michal Hocko wrote: > [Forgot Hugh] > > On Tue 14-05-19 16:41:05, Michal Hocko wrote: > > [This is adding a new user visible interface so you should be CCing > > linux-api mailing list. Also CC Hugh for KSM in general. Done now] Right, thanks for taking care of this. > > On Tue 14-05-19 15:16:50, Oleksandr Natalenko wrote: > > > By default, 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. > > > > > > Instead, lets implement a sysfs knob, which allows marking VMAs as > > > mergeable. This can be used manually on some task in question or by some > > > small userspace helper daemon. > > > > > > The knob is named "force_madvise", and it is write-only. It accepts a PID > > > to act on. To mark the VMAs as mergeable, use: > > > > > > # echo PID > /sys/kernel/mm/ksm/force_madvise > > > > > > To unmerge all the VMAs, use the same approach, prepending the PID with > > > the "minus" sign: > > > > > > # echo -PID > /sys/kernel/mm/ksm/force_madvise > > > > > > This patchset is based on earlier Timofey's submission [1], but it doesn't > > > use dedicated kthread to walk through the list of tasks/VMAs. Instead, > > > it is up to userspace to traverse all the tasks in /proc if needed. > > > > > > The previous suggestion [2] was based on amending do_anonymous_page() > > > handler to implement fully automatic mode, but this approach was > > > incorrect due to improper locking and not desired due to excessive > > > complexity. > > > > > > The current approach just implements minimal interface and leaves the > > > decision on how and when to act to userspace. > > > > Please make sure to describe a usecase that warrants adding a new > > interface we have to maintain for ever. I think of two major consumers of this interface: 1) hosts, that run containers, especially similar ones and especially in a trusted environment; 2) heavy applications, that can be run in multiple instances, not limited to opensource ones like Firefox, but also those that cannot be modified. I'll add this justification to the cover letter once I send another iteration of this submission if necessary. Thank you. > > > > > > > > Thanks. > > > > > > [1] https://lore.kernel.org/patchwork/patch/1012142/ > > > [2] http://lkml.iu.edu/hypermail/linux/kernel/1905.1/02417.html > > > > > > Oleksandr Natalenko (4): > > > mm/ksm: introduce ksm_enter() helper > > > mm/ksm: introduce ksm_leave() helper > > > mm/ksm: introduce force_madvise knob > > > mm/ksm: add force merging/unmerging documentation > > > > > > Documentation/admin-guide/mm/ksm.rst | 11 ++ > > > mm/ksm.c | 160 +++++++++++++++++++++------ > > > 2 files changed, 137 insertions(+), 34 deletions(-) > > > > > > -- > > > 2.21.0 > > > > > > > -- > > Michal Hocko > > SUSE Labs > > -- > Michal Hocko > SUSE Labs -- Best regards, Oleksandr Natalenko (post-factum) Senior Software Maintenance Engineer