Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp4995434imu; Mon, 12 Nov 2018 22:34:29 -0800 (PST) X-Google-Smtp-Source: AJdET5eyb/h35xYTdXvl6FradrGH/rnnOlHdWKrXtRtdh/4nO5peHoTB24t4TBKVz9L/V3lSdBPl X-Received: by 2002:a62:184e:: with SMTP id 75mr3858490pfy.28.1542090869834; Mon, 12 Nov 2018 22:34:29 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1542090869; cv=none; d=google.com; s=arc-20160816; b=eNVvKGnTgebcFjQLE3Qb64MrNemDJiHcuif2arTkkZ/GFAUHbfz03lsyKzEa4fdpbC OjG0HcEq6qEiZbWPOZl5RaI7PZisS2nOkgAzY4CYImHF2/e5Gf23re4voWFXYqSfyZ0/ 74N9brRoSvQQF3PU0P/6BCrEp6cyVa3s3wae+GCYFO5/ha1Plr/QUr5kkKSPOmQJVhC3 DHskK/XpECHx9aTx+DZtdKUQkTGf9FeJaPYjXLF1rCQ/d/bWQi5CkNhe/VJrwlojqvna PFjLErABBysMiCaZb1sajXY01Z7YlJCwltdwg/cTtXw1H82Fk9nsQXcVfVZABzSU0I4i jVig== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:to:references:in-reply-to:message-id:date :subject:cc:from; bh=jMLb2BKzmXBCJuzHEvroGcLpPS2Cq9AGTSdXYh98axA=; b=DLT4Y8JAQJCGvDmeALtJBEFsTmpcqIUZacdzYTdvrHAvbXxttgVBXyIak31ViN3j/v l6Ln/zeEAAuVph0M4M2WwCQp7yWOG1QtPhRsRmZGCAZhyVfIP5STU0BYi02le+XStGHW SuhnxE1pzk94L/EhMa3OkJY7b/NXwY0hRgpKtCHf6CXBCRrEGx5Ade6WY52y3hGxyU3K Bt0bqVK17DycWl4GPbPJPBoFITbrOWJwZwwasg4EEHAkX7SuYUbIUNa+ectbemeObK6F pF5Cp9k9spNrdhS1tbxWfQ8MITaDYPfcN1YAFslEqQlX7PG0Cel/Qb1jgVraXN7pCfoS B1yQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id e6si12459140pgd.428.2018.11.12.22.34.12; Mon, 12 Nov 2018 22:34:29 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731012AbeKMQaK (ORCPT + 99 others); Tue, 13 Nov 2018 11:30:10 -0500 Received: from alexa-out-blr-02.qualcomm.com ([103.229.18.198]:5128 "EHLO alexa-out-blr.qualcomm.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1730965AbeKMQaK (ORCPT ); Tue, 13 Nov 2018 11:30:10 -0500 X-IronPort-AV: E=Sophos;i="5.54,498,1534789800"; d="scan'208";a="237826" Received: from ironmsg03-blr.qualcomm.com ([10.86.208.132]) by alexa-out-blr.qualcomm.com with ESMTP/TLS/AES256-SHA; 13 Nov 2018 12:03:29 +0530 X-IronPort-AV: E=McAfee;i="5900,7806,9075"; a="2020981" Received: from blr-ubuntu-104.ap.qualcomm.com (HELO blr-ubuntu-104.qualcomm.com) ([10.79.40.64]) by ironmsg03-blr.qualcomm.com with ESMTP; 13 Nov 2018 12:03:29 +0530 Received: by blr-ubuntu-104.qualcomm.com (Postfix, from userid 346745) id 30C18269C; Tue, 13 Nov 2018 12:03:28 +0530 (IST) From: Arun KS Cc: keescook@chromium.org, khlebnikov@yandex-team.ru, minchan@kernel.org, getarunks@gmail.com, gregkh@linuxfoundation.org, akpm@linux-foundation.org, mhocko@kernel.org, vbabka@suse.cz, linux-kernel@vger.kernel.org, linux-mm@kvack.org, vatsa@codeaurora.org, willy@infradead.org, Arun KS Subject: [PATCH v5 4/4] mm: Remove managed_page_count spinlock Date: Tue, 13 Nov 2018 12:03:10 +0530 Message-Id: <1542090790-21750-5-git-send-email-arunks@codeaurora.org> X-Mailer: git-send-email 1.9.1 In-Reply-To: <1542090790-21750-1-git-send-email-arunks@codeaurora.org> References: <1542090790-21750-1-git-send-email-arunks@codeaurora.org> To: unlisted-recipients:; (no To-header on input) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Now that totalram_pages and managed_pages are atomic varibles, no need of managed_page_count spinlock. The lock had really a weak consistency guarantee. It hasn't been used for anything but the update but no reader actually cares about all the values being updated to be in sync. Signed-off-by: Arun KS Reviewed-by: Konstantin Khlebnikov Acked-by: Michal Hocko Acked-by: Vlastimil Babka --- include/linux/mmzone.h | 6 ------ mm/page_alloc.c | 5 ----- 2 files changed, 11 deletions(-) diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h index e73dc31..c71b4d9 100644 --- a/include/linux/mmzone.h +++ b/include/linux/mmzone.h @@ -428,12 +428,6 @@ struct zone { * Write access to present_pages at runtime should be protected by * mem_hotplug_begin/end(). Any reader who can't tolerant drift of * present_pages should get_online_mems() to get a stable value. - * - * Read access to managed_pages should be safe because it's unsigned - * long. Write access to zone->managed_pages and totalram_pages are - * protected by managed_page_count_lock at runtime. Idealy only - * adjust_managed_page_count() should be used instead of directly - * touching zone->managed_pages and totalram_pages. */ atomic_long_t managed_pages; unsigned long spanned_pages; diff --git a/mm/page_alloc.c b/mm/page_alloc.c index f8b64cc..26c5e14 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -122,9 +122,6 @@ }; EXPORT_SYMBOL(node_states); -/* Protect totalram_pages and zone->managed_pages */ -static DEFINE_SPINLOCK(managed_page_count_lock); - atomic_long_t _totalram_pages __read_mostly; EXPORT_SYMBOL(_totalram_pages); unsigned long totalreserve_pages __read_mostly; @@ -7065,14 +7062,12 @@ static int __init cmdline_parse_movablecore(char *p) void adjust_managed_page_count(struct page *page, long count) { - spin_lock(&managed_page_count_lock); atomic_long_add(count, &page_zone(page)->managed_pages); totalram_pages_add(count); #ifdef CONFIG_HIGHMEM if (PageHighMem(page)) totalhigh_pages_add(count); #endif - spin_unlock(&managed_page_count_lock); } EXPORT_SYMBOL(adjust_managed_page_count); -- 1.9.1