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.1 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A, 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 0C4DCC433E0 for ; Tue, 23 Feb 2021 13:45:32 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id A1A5D64E3F for ; Tue, 23 Feb 2021 13:45:31 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A1A5D64E3F Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=codeaurora.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id C40996B006E; Tue, 23 Feb 2021 08:45:30 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id BEFDE6B0070; Tue, 23 Feb 2021 08:45:30 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B05B76B0071; Tue, 23 Feb 2021 08:45:30 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0005.hostedemail.com [216.40.44.5]) by kanga.kvack.org (Postfix) with ESMTP id 9C12D6B006E for ; Tue, 23 Feb 2021 08:45:30 -0500 (EST) Received: from smtpin22.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 6212C180ACEE4 for ; Tue, 23 Feb 2021 13:45:30 +0000 (UTC) X-FDA: 77849654820.22.92D3174 Received: from z11.mailgun.us (z11.mailgun.us [104.130.96.11]) by imf15.hostedemail.com (Postfix) with ESMTP id 989DBA0002D3 for ; Tue, 23 Feb 2021 13:45:27 +0000 (UTC) DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=mg.codeaurora.org; q=dns/txt; s=smtp; t=1614087929; h=Content-Transfer-Encoding: Content-Type: In-Reply-To: MIME-Version: Date: Message-ID: From: References: Cc: To: Subject: Sender; bh=q+9rPbpfOFwFc2NgncWfqaEw2Cv1mL6rgZsV2hVae08=; b=dspWTgKy4R5X8N+vTywrDq8hNOSa8idNBMbWv354LDaU+qLeWwnPxJBX6FhHqVE6ue3jcr5T OeNLDhUSrV3qGvSzgKHe4t98URnS9MQnKM5SqtqIbjEI9x9q7W+ndmtWQptOsKLsAFllTe/Q bfCGfD1fIoAuCSOAnCx4IXRCsek= X-Mailgun-Sending-Ip: 104.130.96.11 X-Mailgun-Sid: WyIwY2Q3OCIsICJsaW51eC1tbUBrdmFjay5vcmciLCAiYmU5ZTRhIl0= Received: from smtp.codeaurora.org (ec2-35-166-182-171.us-west-2.compute.amazonaws.com [35.166.182.171]) by smtp-out-n06.prod.us-east-1.postgun.com with SMTP id 603506f64511108a81ea5664 (version=TLS1.2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256); Tue, 23 Feb 2021 13:45:26 GMT Received: by smtp.codeaurora.org (Postfix, from userid 1001) id 9046DC433CA; Tue, 23 Feb 2021 13:45:25 +0000 (UTC) Received: from [192.168.29.110] (unknown [49.37.158.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: charante) by smtp.codeaurora.org (Postfix) with ESMTPSA id B11B5C433C6; Tue, 23 Feb 2021 13:45:21 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org B11B5C433C6 Authentication-Results: aws-us-west-2-caf-mail-1.web.codeaurora.org; dmarc=none (p=none dis=none) header.from=codeaurora.org Authentication-Results: aws-us-west-2-caf-mail-1.web.codeaurora.org; spf=fail smtp.mailfrom=charante@codeaurora.org Subject: Re: [PATCH RFC 0/1] mm: balancing the node zones occupancy To: Vlastimil Babka , akpm@linux-foundation.org, rientjes@google.com, mhocko@suse.com, david@redhat.com, mgorman@techsingularity.net, linux-mm@kvack.org Cc: vinmenon@codeaurora.org, sudaraja@codeaurora.org, linux-kernel@vger.kernel.org, Dave Hansen References: <1c445421-ddeb-8768-03d0-81537b0d1875@suse.cz> From: Charan Teja Kalla Message-ID: Date: Tue, 23 Feb 2021 19:15:19 +0530 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: <1c445421-ddeb-8768-03d0-81537b0d1875@suse.cz> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 989DBA0002D3 X-Stat-Signature: qheo9g57e9ex6fn7so4ugwmkmfpifnxh Received-SPF: none (mg.codeaurora.org>: No applicable sender policy available) receiver=imf15; identity=mailfrom; envelope-from=""; helo=z11.mailgun.us; client-ip=104.130.96.11 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1614087927-685079 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: Thanks Vlastimil for the review comments!! On 2/19/2021 4:56 PM, Vlastimil Babka wrote: > Can you share the use case for doing this? If it's to replace a failed RAM, then > it's probably extremely rare, right. > >> We have the proof-of-concept code tried on the Snapdragon systems with >> the system configuration, single memory node of just 2 zones, 6GB normal >> zone and 2GB movable zone. And this Movable zone is such that hot-added >> once and there after offline/online based on the need. > Hm, snapdragon... so is this some kind of power saving thing? > You are correct. This is the power saving usecase which does the offline and online of the memory blocks in the system by the user. This is not a failed RAM. > Anyway, shouln't auto NUMA balancing help here, and especially "Migrate Pages in > lieu of discard" (CC'd Dave) as a generic mechanism, On the Snapdragon systems we have got only single memory node with Normal and movable zones. And my little understanding is that on most embedded systems we will just have single memory node. My limited understanding about this auto NUMA balancing is that there should be min. 2 nodes for this balancing to trigger. Please correct if I am wrong here. If I am correct then this approach is not suitable for us. Moreover the idea I would like to convey in this RFC patch is about __balancing the zones in a node but not across NUMA nodes__. > so we wouldn't need to have hotplug-specific actions? David has told a very simple view of this problem which is nothing todo with the hotplug specific actions. With just 2 zones(Normal and Movable) in a single node in the system, 1. Application 1 allocates a lot of memory and gets ZONE_MOVABLE. 2. Application 2 allocates a lot of memory and gets ZONE_NORMAL. 3. Application 1 quits. Then after step3, we can expect a lot free memory in the Movable zone but normal zone is under pressure. Applying the similar semantics of Auto numa balancing("Migrate pages in lieu of swap/discard"), we could migrate some eligible pages of Application 2 to Movable zone there by can relieve some pressure in Normal zone. -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project