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 X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 17BC6C3F2D8 for ; Tue, 3 Mar 2020 17:59:16 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id D8BF8217F4 for ; Tue, 3 Mar 2020 17:59:15 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D8BF8217F4 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linutronix.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 5D7A16B0005; Tue, 3 Mar 2020 12:59:15 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 587896B0006; Tue, 3 Mar 2020 12:59:15 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 475BD6B0007; Tue, 3 Mar 2020 12:59:15 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0226.hostedemail.com [216.40.44.226]) by kanga.kvack.org (Postfix) with ESMTP id 2E1026B0005 for ; Tue, 3 Mar 2020 12:59:15 -0500 (EST) Received: from smtpin16.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id D261F180AD801 for ; Tue, 3 Mar 2020 17:59:14 +0000 (UTC) X-FDA: 76554812628.16.steam99_3391fa2525163 X-HE-Tag: steam99_3391fa2525163 X-Filterd-Recvd-Size: 3755 Received: from Galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by imf38.hostedemail.com (Postfix) with ESMTP for ; Tue, 3 Mar 2020 17:59:14 +0000 (UTC) Received: from bigeasy by Galois.linutronix.de with local (Exim 4.80) (envelope-from ) id 1j9Bp0-0002vG-V7; Tue, 03 Mar 2020 18:59:10 +0100 Date: Tue, 3 Mar 2020 18:59:10 +0100 From: Sebastian Andrzej Siewior To: Andrew Morton Cc: Vlastimil Babka , linux-mm@kvack.org, Thomas Gleixner , Luis Chamberlain , Kees Cook , Iurii Zaikin , Mel Gorman , Linux API Subject: Re: [PATCH v2] mm/compaction: Disable compact_unevictable_allowed on RT Message-ID: <20200303175910.ichnkjkgmz5y2ipb@linutronix.de> References: <20200115161035.893221-1-bigeasy@linutronix.de> <4cf4507b-0632-34e6-5985-df933559af9f@suse.cz> <20200302173516.iysuejilava37psk@linutronix.de> <20200302132531.59a2c9dffe2515d78abaf909@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <20200302132531.59a2c9dffe2515d78abaf909@linux-foundation.org> 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 2020-03-02 13:25:31 [-0800], Andrew Morton wrote: > > index 64aeee1009cab..bbfa59d25eec3 100644 > > --- a/Documentation/admin-guide/sysctl/vm.rst > > +++ b/Documentation/admin-guide/sysctl/vm.rst > > @@ -128,6 +128,7 @@ allowed to examine the unevictable lru (mlocked pag= es) for pages to compact. > > This should be used on systems where stalls for minor page faults are = an > > acceptable trade for large contiguous free memory. Set to 0 to prevent > > compaction from moving pages that are unevictable. Default value is 1. > > +On CONFIG_PREEMPT_RT the default value is 0. >=20 > This doesn't mention that the file is unwritable on -rt, and it doesn't > explain *why* -rt has different behaviour. I updated this bit. > > --- a/kernel/sysctl.c > > +++ b/kernel/sysctl.c > > @@ -1483,7 +1483,11 @@ static struct ctl_table vm_table[] =3D { > > .procname =3D "compact_unevictable_allowed", > > .data =3D &sysctl_compact_unevictable_allowed, > > .maxlen =3D sizeof(int), > > +#ifdef CONFIG_PREEMPT_RT > > + .mode =3D 0444, > > +#else > > .mode =3D 0644, > > +#endif >=20 > This is non-backward-compatible and introduces a possibility that > tested-on-non-rt userspace will fail on -rt kernels. It might be > better to accept the writes, but to ignore them. Probably with a > pr_warn_once() to let people know what we did. Hmm. > But do we really need to take the option away from -rt users? Perhaps > someone wants this feature and can accept the latency hit. How about > switching the default and otherwise leaving the kernel behaviour as-is > and simply emitting a warning letting -rt users know that they might > not want to enable this? I don't think that RT people can live with the latency spike. The problem is that it is not deterministic in terms *when* it happens and *how*long* does it need to complete. Also it is not visible so you end up with additional 100us and you have no idea why. compaction is "okay" in the setup / configuration phase when the mlock() pages aren't around / the RT task is disabled. So it does not disturb the RT load. Allowing the user to change the knob and spitting a warning is probably good. So we have a preferred default and the user is aware if it is changed with or without his knowledge. Let me send a patch in a bit=E2=80=A6 Sebastian