Received: by 2002:a05:6a10:a0d1:0:0:0:0 with SMTP id j17csp2060142pxa; Mon, 3 Aug 2020 06:32:59 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxRY4obm40dRRwOwIYhwhZ4vni92LNTVbC+5i4SxVOvIzdEGChe2eq1Ihulsw+KztdvWL/Y X-Received: by 2002:a05:6402:758:: with SMTP id p24mr5115750edy.35.1596461579659; Mon, 03 Aug 2020 06:32:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1596461579; cv=none; d=google.com; s=arc-20160816; b=IxSwfQqkZBapaWuh2GlgpM+jufY5qSI1KzW9bkaRd4q1XyO9ebrVd5kD6+QybtW6o9 zgUixMBh1h4pLVl4Lka+7JjHvjISzGwkYgoFqb1AOK/2xjFM542TkERCdHkGf68Md5zy h2ZjuaPJ5HQF+EDnoA55w3v8bZybc808OiPb2ULl2O1fdEEJQkRGffkmRa2RoNy2F1fg FYA684lvr883vzxdxlZ7l0wcOo4I6qon1XDsW/kAnYpKG9E2yD/vPe83xj0J9LZKju0p rgfpXqBcb4V0BN9r7JiLxNWFO73vEh3NDZvEX/UtmDYAaPU374RBjLOCB3jlEeuMoUXe CPwA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dmarc-filter :dkim-signature; bh=5lz/yjuFSbfi7AP16DemqYxIyN/7sfSVueFdw1yEZKU=; b=QPIZ5du0MFtIMl+EEL7aSDthdHrum1YFsWKVOoJRZIH7linNY9J7zKU6qJrS050/dW P5IQECNoEgccIeJgyZlUQSfxDSB5PIist2yilylTGVpBG79PWD8UzcfddukWLpppU/ZJ Omv2xQkyV1rOowphks+3PJ5CgSf1MCcEjDvD9jR+sgM6jBeBYDVoqhTUrwJGOvbEN6cU 9ZCA5oXaIWF0iXh/vXauZ7qa3/X8Q0EKI3Nyhz8rod0PXjfO6P0Vx7Ma9yxKGK4C6KLN gi7n4r1y5y2Ynq3NuSQ8DNYp4nTyxU6Ngh/0V9d0rKWFtRlGMLVOH6pRFtCSI/OWpvUC Woyg== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@mg.codeaurora.org header.s=smtp header.b=xdhDCEB5; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id a1si1229361edn.356.2020.08.03.06.32.36; Mon, 03 Aug 2020 06:32:59 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=fail header.i=@mg.codeaurora.org header.s=smtp header.b=xdhDCEB5; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726630AbgHCN3I (ORCPT + 99 others); Mon, 3 Aug 2020 09:29:08 -0400 Received: from mail29.static.mailgun.info ([104.130.122.29]:31336 "EHLO mail29.static.mailgun.info" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726398AbgHCN3I (ORCPT ); Mon, 3 Aug 2020 09:29:08 -0400 DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=mg.codeaurora.org; q=dns/txt; s=smtp; t=1596461347; h=Content-Transfer-Encoding: Content-Type: In-Reply-To: MIME-Version: Date: Message-ID: From: References: Cc: To: Subject: Sender; bh=5lz/yjuFSbfi7AP16DemqYxIyN/7sfSVueFdw1yEZKU=; b=xdhDCEB56/5qVQt4nvInLbSFbXofGuzl2oi5fGyrRygDOqHSLFzgvELjCO586xbD6lwHUJNd NwEDxVVN5Dk0w6qWJ7h5isRk9BPolWIfivZPcUrJleEM57TMHGov2zZeTJvO8bbjLEfSGCq7 H9NprDY5bNozGc5DzXvwfLsDtXQ= X-Mailgun-Sending-Ip: 104.130.122.29 X-Mailgun-Sid: WyI0MWYwYSIsICJsaW51eC1rZXJuZWxAdmdlci5rZXJuZWwub3JnIiwgImJlOWU0YSJd Received: from smtp.codeaurora.org (ec2-35-166-182-171.us-west-2.compute.amazonaws.com [35.166.182.171]) by smtp-out-n07.prod.us-west-2.postgun.com with SMTP id 5f28110f21feae908b7919f3 (version=TLS1.2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256); Mon, 03 Aug 2020 13:28:47 GMT Received: by smtp.codeaurora.org (Postfix, from userid 1001) id 5A305C43395; Mon, 3 Aug 2020 13:28:46 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-caf-mail-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.5 required=2.0 tests=ALL_TRUSTED,NICE_REPLY_A, SPF_NONE autolearn=unavailable autolearn_force=no version=3.4.0 Received: from [192.168.1.103] (unknown [183.83.143.239]) (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 1E264C433C9; Mon, 3 Aug 2020 13:28:43 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org 1E264C433C9 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=none smtp.mailfrom=charante@codeaurora.org Subject: Re: [PATCH] mm, memory_hotplug: update pcp lists everytime onlining a memory block To: David Hildenbrand , akpm@linux-foundation.org, linux-mm@kvack.org Cc: linux-kernel@vger.kernel.org, vinmenon@codeaurora.org References: <1596372896-15336-1-git-send-email-charante@codeaurora.org> From: Charan Teja Kalla Message-ID: Date: Mon, 3 Aug 2020 18:58:42 +0530 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Thanks David for the comments. On 8/3/2020 1:35 PM, David Hildenbrand wrote: > On 02.08.20 14:54, Charan Teja Reddy wrote: >> When onlining a first memory block in a zone, pcp lists are not updated >> thus pcp struct will have the default setting of ->high = 0,->batch = 1. >> This means till the second memory block in a zone(if it have) is onlined >> the pcp lists of this zone will not contain any pages because pcp's >> ->count is always greater than ->high thus free_pcppages_bulk() is >> called to free batch size(=1) pages every time system wants to add a >> page to the pcp list through free_unref_page(). To put this in a word, >> system is not using benefits offered by the pcp lists when there is a >> single onlineable memory block in a zone. Correct this by always >> updating the pcp lists when memory block is onlined. > > I guess such setups are rare ... but I can imagine it being the case > with virtio-mem in the future ... not 100% if this performance > optimization is really relevant in practice ... how did you identify this? Even the Snapdragon hardware that I had tested on contain multiple onlineable memory blocks. But we have the use case in which we online single memory block and once it is filled then online the next block. In the step where single block is onlined, we observed the below pageset params. pagesets cpu: 0 count: 0 high: 0 batch: 1 Once the second block is onlined then only seeing some sane values as below. cpu: 0 count: 32 high: 378 batch: 63 In the above case, till the second block is onlined, no page is held in the pcp list. So, updating the pcp params every time when onlining the memory block is required, as an example in the usecase that I had mentioned. > >> >> Signed-off-by: Charan Teja Reddy >> --- >> mm/memory_hotplug.c | 3 +-- >> 1 file changed, 1 insertion(+), 2 deletions(-) >> >> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c >> index dcdf327..7f62d69 100644 >> --- a/mm/memory_hotplug.c >> +++ b/mm/memory_hotplug.c >> @@ -854,8 +854,7 @@ int __ref online_pages(unsigned long pfn, unsigned long nr_pages, >> node_states_set_node(nid, &arg); >> if (need_zonelists_rebuild) >> build_all_zonelists(NULL); >> - else >> - zone_pcp_update(zone); >> + zone_pcp_update(zone); >> >> init_per_zone_wmark_min(); >> >> > > Does, in general, look sane to me. > > Reviewed-by: David Hildenbrand Thanks for the ACK. > -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project