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 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 6F492C433DB for ; Wed, 3 Mar 2021 14:02:56 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id DC0F964E86 for ; Wed, 3 Mar 2021 14:02:55 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org DC0F964E86 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 37A588D016D; Wed, 3 Mar 2021 09:02:55 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 351A28D0157; Wed, 3 Mar 2021 09:02:55 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2415D8D016D; Wed, 3 Mar 2021 09:02:55 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0244.hostedemail.com [216.40.44.244]) by kanga.kvack.org (Postfix) with ESMTP id 0B9A88D0157 for ; Wed, 3 Mar 2021 09:02:55 -0500 (EST) Received: from smtpin11.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id C1176629 for ; Wed, 3 Mar 2021 14:02:54 +0000 (UTC) X-FDA: 77878729068.11.6FBEC85 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf29.hostedemail.com (Postfix) with ESMTP id E3D802BC2 for ; Wed, 3 Mar 2021 14:02:51 +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=1614780168; 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=Xlwkb0P4zfdTZjpS7NnMK7XBu4IbpFu9H1wZ+MKhYAs=; b=fjLn15Wq5YFyUxD1plKgETCpgFt7Kqr4xEr7onlWMkd6yESW8qv7rqVqDotJUFa+5G7IzU pr3xdqf1Cqb5DQBHEFa5bD8MdqiEziXlkASBtbsAkboGlqMMSzsTda1+dz/gFuih5ZB95F VCErgwAUmpkkLj6hFqUPb6iwFTCacH0= Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id E2AE4AE1F; Wed, 3 Mar 2021 14:02:47 +0000 (UTC) Date: Wed, 3 Mar 2021 15:02:47 +0100 From: Michal Hocko To: Muchun Song Cc: Roman Gushchin , Johannes Weiner , Andrew Morton , Shakeel Butt , LKML , Linux Memory Management List Subject: Re: [External] Re: [PATCH v2] mm: memcontrol: fix kernel stack account Message-ID: References: <20210303093956.72318-1-songmuchun@bytedance.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Stat-Signature: sgb7a47yxp67uk6kgr8d9m71u4f5949o X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: E3D802BC2 Received-SPF: none (suse.com>: No applicable sender policy available) receiver=imf29; identity=mailfrom; envelope-from=""; helo=mx2.suse.de; client-ip=195.135.220.15 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1614780171-281609 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 03-03-21 21:27:24, Muchun Song wrote: > On Wed, Mar 3, 2021 at 6:25 PM Michal Hocko wrote: > > > > On Wed 03-03-21 17:39:56, Muchun Song wrote: > > > For simplification 991e7673859e ("mm: memcontrol: account kernel stack > > > per node") has changed the per zone vmalloc backed stack pages > > > accounting to per node. By doing that we have lost a certain precision > > > because those pages might live in different NUMA nodes. In the end > > > NR_KERNEL_STACK_KB exported to the userspace might be over estimated on > > > some nodes while underestimated on others. > > > > > > This doesn't impose any real problem to correctnes of the kernel > > > behavior as the counter is not used for any internal processing but it > > > can cause some confusion to the userspace. > > > > You have skipped over one part of the changelog I have proposed and that > > is to provide an actual data. > > Because this is a problem I found by looking at the code, not a real world > problem. I do not have any actual data. :-( As I've mentioned several times already, this is all fine but it should be made explicit in the changelog. There might be people spending their time to evaluate this code to find out whether this is something that somebody depend on. [...] > > > - /* All stack pages are in the same node. */ > > > - if (vm) > > > - mod_lruvec_page_state(vm->pages[0], NR_KERNEL_STACK_KB, > > > - account * (THREAD_SIZE / 1024)); > > > - else > > > + BUG_ON(vm->nr_pages != THREAD_SIZE / PAGE_SIZE); > > > > I do not think we need this BUG_ON. What kind of purpose does it serve? > > vm->nr_pages should be always equal to THREAD_SIZE / PAGE_SIZE > if the system is not corrupted. BUG_ON is not an annotation for "this shouldn't happen". Even if the system was corrupted and nr_pages wouldn't match then this is not a reason to crash the kernel right away. In general there should be a very _strong_ reason to add a BUG_ON. -- Michal Hocko SUSE Labs