Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp3712448imu; Sun, 11 Nov 2018 22:08:51 -0800 (PST) X-Google-Smtp-Source: AJdET5fshf3pOncw4tII1yAs6C8bKqgtaaC8k/qv1XJVUxqeq1xqiF6voq+X5lE/9AAdbJ7nS0bt X-Received: by 2002:a62:b43:: with SMTP id t64-v6mr1433917pfi.87.1542002931397; Sun, 11 Nov 2018 22:08:51 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1542002931; cv=none; d=google.com; s=arc-20160816; b=JaaerKhf9irPmkYFBz2XzvqYkxD7L5IBgzqlCh7FQ55zjZ8r1cmZ612Ajij4OZuiwZ yeAG6HwgkW4w0uhKVpdAPh8RcMhQCmZQ3tQP3LAZHhEV/3mS1NgNEoRvyFJZxpo07jKp Q/N0qtraOyCmYm5/DiPx4SlrUSE7X//swXg9pXjnNRteptEZTQuxefbmdaCQSv586R+y qE69nRauLoL5gDle+KKeikWsUnjWhNpF5Saf2MH2cP/2gL6l59bRC9cG/L78KBiacFy+ gDFamooBEFWPt+FTMV4t5EJb8Gs2EQTZ6N9H8KWOB1cwt4oolyi3kJHtbd4+wnsHBSVi wXwA== 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=yk0HjirteiEZB3/YJDhid6GWmc/E0Jt+U1e7AzAsMcLFXW886tz+Xs0bcqZKRw0YUT 3tKdGXVwTl0eYpKbJtnizdgg1DsyINoJE5HuvzIoCiI0K9kdU6bxovrFF/tr6Zxc/zdS 67dRfWQLvzZjUWClQQMKGv7Zt9Mcy2C9Img6ART4IAES7gjJIL3xXPqis/kRyw1Jo/RU skqqvstxt7xEW8mGvA8P2g77YCfZ7bfmALh+VdtZuFITsnBCVX0UrlZdeh+S0dKQn8M2 qSWeUmpoV2WvBRNgGw9VsceRTjQOn6a7NzPgqNdKvXjCrJ9LFUkn2xo6wS+B6OK3g8y2 TM1g== 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 a61-v6si17455394plc.35.2018.11.11.22.08.36; Sun, 11 Nov 2018 22:08:51 -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 S1731837AbeKLP76 (ORCPT + 99 others); Mon, 12 Nov 2018 10:59:58 -0500 Received: from alexa-out-blr-01.qualcomm.com ([103.229.18.197]:17745 "EHLO alexa-out-blr-01.qualcomm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731704AbeKLP75 (ORCPT ); Mon, 12 Nov 2018 10:59:57 -0500 X-IronPort-AV: E=Sophos;i="5.54,494,1534789800"; d="scan'208";a="282851" Received: from ironmsg01-blr.qualcomm.com ([10.86.208.130]) by alexa-out-blr-01.qualcomm.com with ESMTP/TLS/AES256-SHA; 12 Nov 2018 11:38:10 +0530 X-IronPort-AV: E=McAfee;i="5900,7806,9074"; a="5747618" Received: from blr-ubuntu-104.ap.qualcomm.com (HELO blr-ubuntu-104.qualcomm.com) ([10.79.40.64]) by ironmsg01-blr.qualcomm.com with ESMTP; 12 Nov 2018 11:38:08 +0530 Received: by blr-ubuntu-104.qualcomm.com (Postfix, from userid 346745) id 96C2924B7; Mon, 12 Nov 2018 11:38:08 +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, Arun KS Subject: [PATCH v4 4/4] mm: Remove managed_page_count spinlock Date: Mon, 12 Nov 2018 11:37:49 +0530 Message-Id: <1542002869-16704-5-git-send-email-arunks@codeaurora.org> X-Mailer: git-send-email 1.9.1 In-Reply-To: <1542002869-16704-1-git-send-email-arunks@codeaurora.org> References: <1542002869-16704-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