From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0AA86C433EF for ; Thu, 19 May 2022 06:23:35 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4A11C6B0072; Thu, 19 May 2022 02:23:35 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 429F26B0073; Thu, 19 May 2022 02:23:35 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2A5396B0074; Thu, 19 May 2022 02:23:35 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 1495F6B0072 for ; Thu, 19 May 2022 02:23:35 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id D6F0732168 for ; Thu, 19 May 2022 06:23:34 +0000 (UTC) X-FDA: 79481501148.19.16DE0F0 Received: from mail-pl1-f171.google.com (mail-pl1-f171.google.com [209.85.214.171]) by imf14.hostedemail.com (Postfix) with ESMTP id BDDE91000E3 for ; Thu, 19 May 2022 06:23:31 +0000 (UTC) Received: by mail-pl1-f171.google.com with SMTP id i17so3903500pla.10 for ; Wed, 18 May 2022 23:23:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:from:to:cc:subject:references:mime-version :content-disposition:in-reply-to; bh=dU3DINgtfDGFvxrO8vrzH5gTpYaPOj3EtI0Lxev004k=; b=P9W2ao+X1j8o0e4M3FlE51sp3ZbX3kE6OaySix0Nr61fzvDANNnziV6sn4i0OFOuQb fnL6nP43cKR4E1RS0Ne2keCb+AkGQPT9y8ZPd6G32GtOgD+5MIeRrANHYRmlE7Ep5hGz Y6JPNIoB+Q0BZ/oMJmulRfJ60JVL8dmzgECHEtp9OYAhGkeunjdp17a8pupShmNPinaU JzCaDrAkxVMUKS9MHQjYBPMSizldkrKM7Z7fqvcp0N9w84qm/HZAzzWcHXuDY6qaAbxN Y/rB+0OStlQdUsmwlr5b78RECyJyCescD02nI86iYRRtnnwtGmXbAivv2KStLk79Uj8l nvOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:from:to:cc:subject:references :mime-version:content-disposition:in-reply-to; bh=dU3DINgtfDGFvxrO8vrzH5gTpYaPOj3EtI0Lxev004k=; b=qF6TZ88YEyjkwf9AvLE7gnU1DWII8FaBa+mLZqgYb0SL6YuBBfL3Z5YObOHKvizpII iZYkLvHjMef4g8k6wWo57lt1xe7wwJYyIv4bLEMmhkKMAc51jKbUR6ikg2omG3l6VJDw /HvxakrjDaNjZd6dxhFi4L17zZOV3n3f0iJsEfQfeP/a9l1/kVcJx/uMrCwifMc3nmo1 c5I70B2vVFJRJMQB3OYz0pBAn5U7yNFlyzBeMRAY4Ys627MOOGDKJ2WR5fAeYz9i1tH9 bu3Z68ePV56c+5sMYY6s82zarE9kXbfXjZb7TMK9Z9TPmWCH6lvKzUeBzAv813eAI5C1 VYJA== X-Gm-Message-State: AOAM5305IdS6ycJd2JGgPT+NqcBavI9gvf2I+npS37x3G+HUdkbwahY+ 6ovY/MqksbCn0q2UqO6Px/s= X-Google-Smtp-Source: ABdhPJyxzQAh4x9PryBtqoGQKFBgbbAygSGM6ZDhTgWcBRb9YCR0GTecP+DjRQ+BYAA7pFaWwznVqw== X-Received: by 2002:a17:902:ba8c:b0:161:5ad4:1800 with SMTP id k12-20020a170902ba8c00b001615ad41800mr3412938pls.9.1652941413377; Wed, 18 May 2022 23:23:33 -0700 (PDT) Received: from localhost ([193.203.214.57]) by smtp.gmail.com with ESMTPSA id y23-20020a17090264d700b0015e8d4eb204sm2815041pli.78.2022.05.18.23.23.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 18 May 2022 23:23:32 -0700 (PDT) Message-ID: <6285e264.1c69fb81.3f416.71a8@mx.google.com> X-Google-Original-Message-ID: <20220519062330.GA1735877@cgel.zte@gmail.com> Date: Thu, 19 May 2022 06:23:30 +0000 From: CGEL To: Michal Hocko Cc: akpm@linux-foundation.org, ammarfaizi2@gnuweeb.org, oleksandr@natalenko.name, willy@infradead.org, linux-mm@kvack.org, corbet@lwn.net, linux-kernel@vger.kernel.org, xu xin , Yang Yang , Ran Xiaokai , wangyong , Yunkai Zhang , Jiang Xuexin , Hugh Dickins , linux-api@vger.kernel.org Subject: Re: [PATCH] mm/ksm: introduce ksm_enabled for each process References: <20220517092701.1662641-1-xu.xin16@zte.com.cn> <62845e2b.1c69fb81.cbf4a.1200@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: BDDE91000E3 Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=P9W2ao+X; spf=pass (imf14.hostedemail.com: domain of cgel.zte@gmail.com designates 209.85.214.171 as permitted sender) smtp.mailfrom=cgel.zte@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Rspam-User: X-Stat-Signature: 9of69qugsfxgbarf74ufibcq6i6utkob X-HE-Tag: 1652941411-547460 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, May 18, 2022 at 02:12:26PM +0200, Michal Hocko wrote: > On Wed 18-05-22 02:47:06, CGEL wrote: > > On Tue, May 17, 2022 at 04:04:38PM +0200, Michal Hocko wrote: > > > [CCing Hugh and linux-api] > > > > > > On Tue 17-05-22 09:27:01, cgel.zte@gmail.com wrote: > > > > From: xu xin > > > > > > > > For now, if we want to use KSM to merge pages of some apps, we have to > > > > explicitly call madvise() in application code, which means installed > > > > apps on OS needs to be uninstall and source code needs to be modified. > > > > It is very inconvenient because sometimes users or app developers are not > > > > willing to modify their app source codes for any reasons. > > > > Hello, Michal. > > > > > > Would it help to allow external control by process_madvise? > > > > > > > Maybe, but it will be much more complicated to achieve this by > > process_madvise(). process_madvise works on a serires of VMAs in > > essential, So all the eligible VMAs have to be traversed. The problem > > about this has been discussed in [1],[2]. > > [1]https://lore.kernel.org/lkml/1835064.A2aMcgg3dW@natalenko.name/ > > [2]https://lore.kernel.org/lkml/20220513133210.9dd0a4216bd8baaa1047562c@linux-foundation.org/ > > I can see that this is not a trivial interface to use but I do not > think this would be too hard to be usable. There is certainly some > coordination required between the external and the target tasks. But > that is to be expected IMHO. You do not really want to configure merging > without actually understanding what the application does and whether > that is really OK. Right? > > Besides that, as far as I remember, the process_madvise interface > doesn't really require exact vmas to be provided and a single range can > span multiple VMAs. Yes, but all the eligible VMAs still have to be traversed after all. It may induce more latency than needed because the target task has to be stopped to avoid races. > > > > > So to use KSM more flexibly, we provide a new proc file "ksm_enabled" under > > > > /proc//. We can pass parameter into this file with one of three values > > > > as follows: > > > > > > > > always: > > > > force all anonymous and eligible VMAs of this process to be > > > > scanned by ksmd. > > > > madvise: > > > > the default state, unless user code call madvise, ksmd > > > > doesn't scan this process. > > > > never: > > > > this process will never be scanned by ksmd and no merged > > > > pages occurred in this process. > > > > > > > > With this patch, we can control KSM with ``/proc//ksm_enabled`` > > > > based on every process. KSM for each process can be entirely disabled > > > > (mostly for debugging purposes) or only enabled inside MADV_MERGEABLE > > > > regions (to avoid the risk of consuming more cpu resources to scan for > > > > ksmd) or enabled entirely for a process. > > > > > > I am not really familiar with KSM much but I am wondering whether the > > > proc based interface is really the best fit. We have a very similar > > > concern with THP where processes would like to override the global setup > > > and that has been done with prctl interface. Is there any reason why > > > this should be any different? > > > > > At least for now, I can't find a simpler implementation than proc file, > > unless we add a new syscall used for changing another process mm's flag > > in user space. > > What is the problem with the prctl extension? > What's the meaning of the prctl extension? I don't quite get your point. Can prctl control external process? > > Speaking to THP, the interactive UI of KSM is relatively simpler because > > KSM dosen't have global knob like THP. OTOH, THP trades space for time > > (consume memory) while KSM trades time for space (save memory), so THP > > tends to be enabled system wide while KSM not. > > > > > Another question I have is about the interaction of the per-process > > > tunable with any explicit madvise calls. AFAICS you have made this knob > > > per mm but the actual implementation currently relies on the per-vma > > > flags. That means that one can explicitly disallow merging by madvise > > > for a range. Is it wise to override that by a per-process knob? I mean > > > there might be a very good reason why a particular memory ranges should > > > never be merged but a per-process knob could easily ignore that hint > > > from the application. Or am I just confuse? > > For now, there is no any hints for letting KSM never merge some memory > > ranges. > > I am not sure I understand. Could you be more specific? Not like THP, KSM doesn't have anything like VM_NOHUGEPAGE, so apps cann't explicitly disallow merging by madvise. If it is really necessary for a particular meory ranges of a process to be never merged, we have to submit one more patch to achieve that. > -- > Michal Hocko > SUSE Labs