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 658A1C433F5 for ; Wed, 11 May 2022 03:12:07 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 01A076B0073; Tue, 10 May 2022 23:12:07 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id F0C366B0075; Tue, 10 May 2022 23:12:06 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DAD656B0078; Tue, 10 May 2022 23:12:06 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id CDA4A6B0073 for ; Tue, 10 May 2022 23:12:06 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay11.hostedemail.com (Postfix) with ESMTP id A929981D1F for ; Wed, 11 May 2022 03:12:06 +0000 (UTC) X-FDA: 79451988252.24.A6DFD93 Received: from mail-pf1-f182.google.com (mail-pf1-f182.google.com [209.85.210.182]) by imf28.hostedemail.com (Postfix) with ESMTP id 63DA9C0093 for ; Wed, 11 May 2022 03:11:46 +0000 (UTC) Received: by mail-pf1-f182.google.com with SMTP id x23so813490pff.9 for ; Tue, 10 May 2022 20:12:05 -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:content-transfer-encoding:in-reply-to; bh=2MBN0zAn4D9ezzvtFqR3BrhbtifUhq904sSLoPSl8Gg=; b=OH3/AiTSfdYV426FLwS5odKSvQ6zAXUDpYal67qusApQXatvj5YUhB8Xnzkd5Uga2N 92qc2Y4cFUAupDnI6aiuK7qkkafx62Vla7PRAn9lwS6+9URIwNp7HZVdbtBazgz4o80X 702IC20TiPakyeONU3K8nSb3lXh4zK+hk+249Js2WkAwTcAPLwPbg/69XDN4YQEOQasT mgYGge8LN8TLkmTT9buWJiZez7aFG34mWAz/Ticup+afm9L+/VIF/UAz7yBx3d5nFnTN rMhZ5FuQ2YZdIpOqulGf9EcKKZuCC4WAaU6uuAtBrJBEmZpcmRpiPrIgFvoCqxSdF+1i lbtA== 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:content-transfer-encoding :in-reply-to; bh=2MBN0zAn4D9ezzvtFqR3BrhbtifUhq904sSLoPSl8Gg=; b=Zt17iLFe3jMN8GrK0vsCYZO0XsZG3BY+IUI2ejYmYd9W6UV+Hkm5VuX7D4N5psA9Qm WpQ56Gm9AWlblaARpevsS5R4qsrMh9OWTOaApfD2GAh0kMoMtVkTv6ya0ibVRYc/891A 4b2rGRidAyqYctfcsyVRknpGKxV7gUohn7TNjjtFox++bFMs9/cVvviISfNZeH7Rkhiw 3osSjp0Hd61TTgGTo2R70UBh95t24ToyQteOxB+BGjSXTkkcwRU/EZaoj6ERAJHxVTVA SlYUl9rrE7GO71CNL2zbAEkDxsyYkYixLt50LKwIC+31KGDLh3BPk+txLzi4NdLS9beh ZbMQ== X-Gm-Message-State: AOAM531+LPtkrbsEPWNBq8wDCeRCInSsEQfvB3YXDlcpfsEIGkqMUJAy OC/gEC5fASX3zt1pxWhZsrw= X-Google-Smtp-Source: ABdhPJwUnDTfZUFHgHXqErgtlhY8Q79APm2Ey84kG+KC6CvYcMygKomgghJWTa+Yd+LiAI0zaxqmEg== X-Received: by 2002:a05:6a00:1a8d:b0:510:510f:d8e1 with SMTP id e13-20020a056a001a8d00b00510510fd8e1mr22928042pfv.83.1652238725019; Tue, 10 May 2022 20:12:05 -0700 (PDT) Received: from localhost ([193.203.214.57]) by smtp.gmail.com with ESMTPSA id d5-20020a170902c18500b0015e8d4eb1d2sm389038pld.28.2022.05.10.20.12.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 10 May 2022 20:12:04 -0700 (PDT) Message-ID: <627b2984.1c69fb81.9002b.15f9@mx.google.com> X-Google-Original-Message-ID: <20220511031203.GA1492365@cgel.zte@gmail.com> Date: Wed, 11 May 2022 03:12:03 +0000 From: CGEL To: Oleksandr Natalenko Cc: akpm@linux-foundation.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, corbet@lwn.net, xu xin , Yang Yang , Ran Xiaokai , wangyong , Yunkai Zhang , Matthew Wilcox Subject: Re: [PATCH v6] mm/ksm: introduce ksm_force for each process References: <20220510122242.1380536-1-xu.xin16@zte.com.cn> <5820954.lOV4Wx5bFT@natalenko.name> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <5820954.lOV4Wx5bFT@natalenko.name> Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b="OH3/AiTS"; spf=pass (imf28.hostedemail.com: domain of cgel.zte@gmail.com designates 209.85.210.182 as permitted sender) smtp.mailfrom=cgel.zte@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Rspam-User: X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 63DA9C0093 X-Stat-Signature: zwxttzhiuzpmai11bmpd8ja9wccbd6k4 X-HE-Tag: 1652238706-209380 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 Tue, May 10, 2022 at 03:30:36PM +0200, Oleksandr Natalenko wrote: > Hello. > > On úterý 10. května 2022 14:22:42 CEST cgel.zte@gmail.com wrote: > > From: xu xin > > > > To use KSM, 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 inconvenient. > > > > In order to change this situation, We add a new proc file ksm_force > > under /proc// to support turning on/off KSM scanning of a > > process's mm dynamically. > > > > If ksm_force is set to 1, force all anonymous and 'qualified' VMAs > > of this mm to be involved in KSM scanning without explicitly calling > > madvise to mark VMA as MADV_MERGEABLE. But It is effective only when > > the klob of /sys/kernel/mm/ksm/run is set as 1. > > > > If ksm_force is set to 0, cancel the feature of ksm_force of this > > process (fallback to the default state) and unmerge those merged pages > > belonging to VMAs which is not madvised as MADV_MERGEABLE of this process, > > but still leave MADV_MERGEABLE areas merged. > > To my best knowledge, last time a forcible KSM was discussed (see threads [1], [2], [3] and probably others) it was concluded that a) procfs was a horrible interface for things like this one; and b) process_madvise() syscall was among the best suggested places to implement this (which would require a more tricky handling from userspace, but still). > > So, what changed since that discussion? > Thanks a lot for your information. However, the patch here is slightly different from your previous discussion: your patch focuses on using procfs to change the madvise behaviour of another process, but this patch will not modify the flag of all VMAs of the process. It introduces a new bool ksm_force to represent this forcible feature of KSM based on process, which is independent of madvise. the same way, process_madvise is a kind of madvise in essence. > P.S. For now I do it via dedicated syscall, but I'm not trying to upstream this approach. > > [1] https://lore.kernel.org/lkml/2a66abd8-4103-f11b-06d1-07762667eee6@suse.cz/ > [2] https://lore.kernel.org/all/20190515145151.GG16651@dhcp22.suse.cz/T/#u > [3] https://lore.kernel.org/lkml/20190516172452.GA2106@avx2/ > [4] https://gitlab.com/post-factum/pf-kernel/-/commits/ksm-5.17/ > > Oleksandr Natalenko (post-factum) >