Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   Oleksandr Natalenko <oleksandr@natalenko.name>
To:     Andrew Morton <akpm@linux-foundation.org>
Cc:     cgel.zte@gmail.com, linux-fsdevel@vger.kernel.org,
        linux-kernel@vger.kernel.org, linux-mm@kvack.org, corbet@lwn.net,
        xu xin <xu.xin16@zte.com.cn>,
        Yang Yang <yang.yang29@zte.com.cn>,
        Ran Xiaokai <ran.xiaokai@zte.com.cn>,
        wangyong <wang.yong12@zte.com.cn>,
        Yunkai Zhang <zhang.yunkai@zte.com.cn>,
        Matthew Wilcox <willy@infradead.org>
Subject: Re: [PATCH v6] mm/ksm: introduce ksm_force for each process
Date:   Fri, 13 May 2022 11:51:53 +0200
Message-ID: <1835064.A2aMcgg3dW@natalenko.name>
In-Reply-To: <20220512153753.6f999fa8f5519753d43b8fd5@linux-foundation.org>
References: <20220510122242.1380536-1-xu.xin16@zte.com.cn> <5820954.lOV4Wx5bFT@natalenko.name> <20220512153753.6f999fa8f5519753d43b8fd5@linux-foundation.org>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

Hello.

On p=C3=A1tek 13. kv=C4=9Btna 2022 0:37:53 CEST Andrew Morton wrote:
> On Tue, 10 May 2022 15:30:36 +0200 Oleksandr Natalenko <oleksandr@natalen=
ko.name> wrote:
>=20
> > > 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.
> > >=20
> > > 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 pro=
cess,
> > > but still leave MADV_MERGEABLE areas merged.
> >=20
> > To my best knowledge, last time a forcible KSM was discussed (see threa=
ds [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() sysc=
all was among the best suggested places to implement this (which would requ=
ire a more tricky handling from userspace, but still).
> >=20
> > So, what changed since that discussion?
> >=20
> > P.S. For now I do it via dedicated syscall, but I'm not trying to upstr=
eam this approach.
>=20
> Why are you patching the kernel with a new syscall rather than using
> process_madvise()?

Because I'm not sure how to use `process_madvise()` to achieve $subj proper=
ly.

The objective is to mark all the eligible VMAs of the target task for KSM t=
o consider them for merging.

=46or that, all the eligible VMAs have to be traversed.

Given `process_madvise()` has got an iovec API, this means the process that=
 will call `process_madvise()` has to know the list of VMAs of the target p=
rocess. In order to traverse them in a race-free manner the target task has=
 to be SIGSTOP'ped or frozen, then the list of VMAs has to be obtained, the=
n `process_madvise()` has to be called, and the the target task can continu=
e. This is:

a) superfluous (the kernel already knows the list of VMAs of the target tas=
ks, why proxy it through the userspace then?); and
b) may induce more latency than needed because the target task has to be st=
opped to avoid races.

OTOH, IIUC, even if `MADV_MERGEABLE` is allowed for `process_madvise()`, I =
cannot just call it like this:

```
iovec.iov_base =3D 0;
iovec.iov_len =3D ~0ULL;
process_madvise(pidfd, &iovec, 1, MADV_MERGEABLE, 0);
```

to cover the whole address space because iovec expects total size to be und=
er ssize_t.

Or maybe there's no need to cover the whole address space, only the lower h=
alf of it?

Or maybe there's another way of doing things, and I just look stupid and do=
 not understand how this is supposed to work?..

I'm more than happy to read your comments on this.

Thanks.

=2D-=20
Oleksandr Natalenko (post-factum)