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.3 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,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 D33F4C47423 for ; Fri, 2 Oct 2020 11:25:20 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 72089206DD for ; Fri, 2 Oct 2020 11:25:20 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=suse.com header.i=@suse.com header.b="Uzfkfqfn" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 72089206DD Authentication-Results: mail.kernel.org; dmarc=fail (p=none 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 B5031900004; Fri, 2 Oct 2020 07:25:19 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B018F900002; Fri, 2 Oct 2020 07:25:19 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9CA58900004; Fri, 2 Oct 2020 07:25:19 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0098.hostedemail.com [216.40.44.98]) by kanga.kvack.org (Postfix) with ESMTP id 6B35B900002 for ; Fri, 2 Oct 2020 07:25:19 -0400 (EDT) Received: from smtpin12.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 05CA78249980 for ; Fri, 2 Oct 2020 11:25:19 +0000 (UTC) X-FDA: 77326754358.12.desk10_3317ba9271a3 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin12.hostedemail.com (Postfix) with ESMTP id D7C7D18010606 for ; Fri, 2 Oct 2020 11:25:18 +0000 (UTC) X-HE-Tag: desk10_3317ba9271a3 X-Filterd-Recvd-Size: 4707 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf43.hostedemail.com (Postfix) with ESMTP for ; Fri, 2 Oct 2020 11:25:18 +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=1601637917; 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=Qa0E0AqAlpJW8exV1CmKJIhcsK2Mdv4336ilHgw89b8=; b=UzfkfqfnuPCur8RZ5Ow5r0GwLHYtvnra2J2t0vwK6HEOqu5MGj1Ox1Bt3R2pShL/1JNj40 CyjUUErSO0LuMGu5FNcUN9btCg7DGN2NyZg81tt7SYYuCCih8ArQRdeDAWW1sA2qnYJOrQ UXJ2JdDn9ejgN7lQdSIdgt0pTDpT9CY= Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 17F18ABD1; Fri, 2 Oct 2020 11:25:17 +0000 (UTC) Date: Fri, 2 Oct 2020 13:25:16 +0200 From: Michal Hocko To: Mike Kravetz Cc: Vijay Balakrishna , Andrew Morton , "Kirill A. Shutemov" , Oleg Nesterov , Song Liu , Andrea Arcangeli , Pavel Tatashin , Allen Pais , linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [v5] mm: khugepaged: recalculate min_free_kbytes after memory hotplug as expected by khugepaged Message-ID: <20201002112516.GD4555@dhcp22.suse.cz> References: <1601398153-5517-1-git-send-email-vijayb@linux.microsoft.com> <2a380b84-4fee-fa4e-e862-8a8577961088@oracle.com> <8cdb105c-2b7b-1997-ed82-22f4bb25638c@linux.microsoft.com> <638ebb7a-72e3-a219-ee2b-55f1c028efad@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <638ebb7a-72e3-a219-ee2b-55f1c028efad@oracle.com> User-Agent: Mutt/1.10.1 (2018-07-13) 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-09-20 15:03:11, Mike Kravetz wrote: > On 9/30/20 1:47 PM, Vijay Balakrishna wrote: > > On 9/30/2020 11:20 AM, Mike Kravetz wrote: > >> On 9/29/20 9:49 AM, Vijay Balakrishna wrote: > >> > >> Sorry for jumping in so late. Should we use this as an opportunity to > >> also fix up the messages logged when (re)calculating mfk? They are wrong > >> and could be quite confusing. > > > > > > Sure. Please share your thoughts regarding appropriate message. Here is what I'm thinking > > > > pr_warn("min_free_kbytes is not updated to %d because current value %d is preferred\n", new_min_free_kbytes, min_free_kbytes); > > > > If above message is reasonable I can post a new revision (v6). > > Just considering the below example, > > >> For example consider the following sequence > >> of operations and corresponding log messages produced. > >> > >> Freshly booted VM with 2 nodes and 8GB memory: > >> # cat /proc/sys/vm/min_free_kbytes > >> 90112 > >> # echo 90000 > /proc/sys/vm/min_free_kbytes > >> # cat /proc/sys/vm/min_free_kbytes > >> 90000 > >> # echo 0 > /sys/devices/system/node/node1/memory56/online > >> [ 135.099947] Offlined Pages 32768 > >> [ 135.102362] min_free_kbytes is not updated to 11241 because user defined value 90000 is preferred > > I am not sure if there is any value in printing the above line. Especially > in this context as it becomes obsolete with the printing of the next line. The original intention was to make it explicit that auto-tuning is influenced by the user provided configuration. > >> [ 135.109070] khugepaged: raising min_free_kbytes from 90000 to 90112 to help t > >> ransparent hugepage allocations > > IMO, the above line is the only one that should be output as a result of the > recalculation. Well, but khugepaged could be disabled and then the above might not get printed. Sure the code could get reorganized and all that but is this really worth that? > I guess that brings up the question of 'should we continue to track the user > defined value if we overwrite it?". If we quit tracking it may help with the > next message. Auto tuning and user provided override is quite tricky to get sensible. Especially in the case here. Admin has provided an override but has the potential memory hotplug been considered? Or to make it even more complicated, consider that the hotplug happens without admin involvement - e.g. memory gets hotremoved due to HW problems. Is the admin provided value still meaningful? To be honest I do not have a good answer and I am not sure we should care all that much until we see practical problems. -- Michal Hocko SUSE Labs