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=-2.6 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 A0CF9C433DF for ; Mon, 29 Jun 2020 23:30:53 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 6357620780 for ; Mon, 29 Jun 2020 23:30:53 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="QVAa5Shu" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6357620780 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id E154E8D0016; Mon, 29 Jun 2020 19:30:52 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DC59B8D000F; Mon, 29 Jun 2020 19:30:52 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CB3E38D0016; Mon, 29 Jun 2020 19:30:52 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0003.hostedemail.com [216.40.44.3]) by kanga.kvack.org (Postfix) with ESMTP id B5ACA8D000F for ; Mon, 29 Jun 2020 19:30:52 -0400 (EDT) Received: from smtpin02.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 2D8F31EE6 for ; Mon, 29 Jun 2020 23:30:52 +0000 (UTC) X-FDA: 76983846744.02.shoes58_311547e26e73 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin02.hostedemail.com (Postfix) with ESMTP id 0616E200024975A9 for ; Mon, 29 Jun 2020 23:30:52 +0000 (UTC) X-HE-Tag: shoes58_311547e26e73 X-Filterd-Recvd-Size: 5231 Received: from us-smtp-delivery-1.mimecast.com (us-smtp-2.mimecast.com [207.211.31.81]) by imf13.hostedemail.com (Postfix) with ESMTP for ; Mon, 29 Jun 2020 23:30:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1593473450; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=J4yvYvAixEsOBHxzNK+u9dCnbkwzUtROOEW2TKDDrHo=; b=QVAa5ShuubLPsqrDuIqGH2Lxryla2yyVXvEFKslRmUSja+tcNVCA53p3mi3pE0GmoP9hdb oo4khM6E3Mh4Zp0HWIH84VZFREkripCvUlTXsrsgHE4np2Zny+6sBOOofRW8kK3wuqjQxK L91mEVj68GiLSD/Ei44J3IvyDy+V1J0= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-463-kG66Rb4yN2SGdD26cHNb3A-1; Mon, 29 Jun 2020 19:30:48 -0400 X-MC-Unique: kG66Rb4yN2SGdD26cHNb3A-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id C8443107ACCA; Mon, 29 Jun 2020 23:30:46 +0000 (UTC) Received: from localhost (ovpn-12-47.pek2.redhat.com [10.72.12.47]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 1019D5D9D7; Mon, 29 Jun 2020 23:30:45 +0000 (UTC) Date: Tue, 30 Jun 2020 07:30:43 +0800 From: Baoquan He To: Dave Hansen Cc: Dave Hansen , linux-kernel@vger.kernel.org, linux-mm@kvack.org, ben.widawsky@intel.com, alex.shi@linux.alibaba.com, dwagner@suse.de, tobin@kernel.org, cl@linux.com, akpm@linux-foundation.org, stable@kernel.org Subject: Re: [PATCH] mm/vmscan: restore zone_reclaim_mode ABI Message-ID: <20200629233043.GK3346@MiWiFi-R3L-srv> References: <20200626003459.D8E015CA@viggo.jf.intel.com> <20200629065203.GJ3346@MiWiFi-R3L-srv> <3ba94f19-3b18-9d52-a070-f652620c88e6@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3ba94f19-3b18-9d52-a070-f652620c88e6@intel.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Rspamd-Queue-Id: 0616E200024975A9 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam02 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 06/29/20 at 07:27am, Dave Hansen wrote: > On 6/28/20 11:52 PM, Baoquan He wrote: > > On 06/25/20 at 05:34pm, Dave Hansen wrote: > >> > >> From: Dave Hansen > >> > >> I went to go add a new RECLAIM_* mode for the zone_reclaim_mode > >> sysctl. Like a good kernel developer, I also went to go update the > >> documentation. I noticed that the bits in the documentation didn't > >> match the bits in the #defines. > >> > >> The VM evidently stopped caring about RECLAIM_ZONE at some point (or > >> never cared) and the #define itself was later removed as a cleanup. > > > >>From git history, it seems to never care about the RECLAIM_ZONE bit. > > > > I think this patch is justified. I have one question about adding back > > the RECLAIM_ZONE bit. Since we introduced RECLAIM_ZONE in the first > > place, but never use it, removing it truly may fail some existing > > script, does it mean we will never have chance to fix/clean up this kind > > of mess? > > Our #1 rule is "don't break userspace". We only break userspace when we > have no other choice. > > This case a bit fuzzier because we don't know if anyone is depending on > the ignored bit to do anything. But, it *was* documented. To me, that > means it might have been used, even though it would have been a > "placebo" bit. > > > Do we have possibility to remove it in mainline tree, let distos or > > stable kernel maintainer take care of the back porting? Like this, any > > stable kernel after 5.8, or any distrols which chooses post v5.8 kenrel > > as base won't have this confusion. I am not objecting this patch, just > > be curious if we have a way to fix/clean up for this type of issue. > > The only way I can plausibly think of "cleaning up" the RECLAIM_ZONE bit > would be to raise our confidence that it is truly unused. That takes > time, and probably a warning if we see it being set. If we don't run > into anybody setting it or depending on it being set in a few years, we > can remove it. So adding the old bit back for compatibility looks good, thanks. Then we have to be very careful when adding and reviewing new interface introducing, should not leave one which might be used in the future. In fact, RECLAIM_ZONE is not completely useless. At least, when the old bit 0 is set, it may enter into node_reclaim() in get_page_from_freelist(), that makes it like a switch. get_page_from_freelist { ... if (node_reclaim_mode == 0 || !zone_allows_reclaim(ac->preferred_zoneref->zone, zone)) continue; ... } > > Backporting a _warning_ into the -stable trees might be an interesting > way to find users of older kernels mucking with it. >