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=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 E1D4AC433E0 for ; Mon, 4 Jan 2021 08:47:43 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 74AFE207BC for ; Mon, 4 Jan 2021 08:47:43 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 74AFE207BC Authentication-Results: mail.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=suse.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id A90156B00A5; Mon, 4 Jan 2021 03:47:42 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A40A76B00A6; Mon, 4 Jan 2021 03:47:42 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 957C56B00A7; Mon, 4 Jan 2021 03:47:42 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0185.hostedemail.com [216.40.44.185]) by kanga.kvack.org (Postfix) with ESMTP id 7F1406B00A5 for ; Mon, 4 Jan 2021 03:47:42 -0500 (EST) Received: from smtpin28.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 48840180AD80F for ; Mon, 4 Jan 2021 08:47:42 +0000 (UTC) X-FDA: 77667464364.28.class78_1e1097d274cf Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin28.hostedemail.com (Postfix) with ESMTP id 299FF6C09 for ; Mon, 4 Jan 2021 08:47:42 +0000 (UTC) X-HE-Tag: class78_1e1097d274cf X-Filterd-Recvd-Size: 2875 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf43.hostedemail.com (Postfix) with ESMTP for ; Mon, 4 Jan 2021 08:47:41 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1609750060; h=from:from:reply-to: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=lqG4UmkZPkzR4Zi5SXqaX9O4JmxRq0adZPH7D9loI+Y=; b=Fl8muME5yB3vL19zQ0uF80xGhufGuQs0GG9x52XThP/w+In1WyVlOJzi2DYH4SXQbHSDrN gOtPAQmKSICkk7DK2rotycPHYpr0p5QYVwIvwLAwH7ard5gD2Qla8MiaEkj9HYlsRS2Rx+ EYzPVl9h83dFnWHYsDYPA1QxUszb920= Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 64AF3ACBA; Mon, 4 Jan 2021 08:47:40 +0000 (UTC) Date: Mon, 4 Jan 2021 09:47:39 +0100 From: Michal Hocko To: Muchun Song Cc: Matthew Wilcox , Hui Su , Andrew Morton , linux-mm@kvack.org, linux-kernel Subject: Re: [PATCH] mm/page_alloc: remove the static for local variable node_order Message-ID: <20210104084739.GB13207@dhcp22.suse.cz> References: <20201230114014.GA1934427@ubuntu-A520I-AC> <20201230124233.GE28221@casper.infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 30-12-20 21:41:30, Muchun Song wrote: > On Wed, Dec 30, 2020 at 8:45 PM Matthew Wilcox wrote: > > > > On Wed, Dec 30, 2020 at 07:40:14PM +0800, Hui Su wrote: > > > local variable node_order do not need the static here. > > > > It bloody well does. It can be up to 2^10 entries on x86 (and larger > > on others) That's 4kB which you've now moved onto the stack. > > This is not the first time I have seen similar changes. So what > do you think about adding a comment here to avoid another one > do this in the feature? Well, this is not an unusual technieque to reduce the stack space. I am not really sure we really need to put an explicit comment about that. I would appreciate much more if patch submitters took an extra step when creating seemingly trivial patches and either consult the history of the respective code or look for a similar pattern elsewhere before sending them. I do agree with Willy that mm code is usually not a great place to search for trivial patches. First of all most people tend to be pretty busy with other reviewes and the code has grown rather delicate and tricky so each review is non trivial. -- Michal Hocko SUSE Labs