Message ID | 20180822093226.25987-1-osalvador@techadventures.net (mailing list archive) |
---|---|
Headers | show
Return-Path: <owner-linux-mm@kvack.org> Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id D26E5139B for <patchwork-linux-mm@patchwork.kernel.org>; Wed, 22 Aug 2018 09:32:35 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id C41C9298D3 for <patchwork-linux-mm@patchwork.kernel.org>; Wed, 22 Aug 2018 09:32:35 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id B72ED2AAEC; Wed, 22 Aug 2018 09:32:35 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.9 required=2.0 tests=BAYES_00,MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 4265E298D3 for <patchwork-linux-mm@patchwork.kernel.org>; Wed, 22 Aug 2018 09:32:35 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 344AA6B23AB; Wed, 22 Aug 2018 05:32:34 -0400 (EDT) Delivered-To: linux-mm-outgoing@kvack.org Received: by kanga.kvack.org (Postfix, from userid 40) id 2F35E6B23AC; Wed, 22 Aug 2018 05:32:34 -0400 (EDT) X-Original-To: int-list-linux-mm@kvack.org X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1BC036B23AD; Wed, 22 Aug 2018 05:32:34 -0400 (EDT) X-Original-To: linux-mm@kvack.org X-Delivered-To: linux-mm@kvack.org Received: from mail-wr1-f71.google.com (mail-wr1-f71.google.com [209.85.221.71]) by kanga.kvack.org (Postfix) with ESMTP id B2D096B23AB for <linux-mm@kvack.org>; Wed, 22 Aug 2018 05:32:33 -0400 (EDT) Received: by mail-wr1-f71.google.com with SMTP id z77-v6so1272434wrb.20 for <linux-mm@kvack.org>; Wed, 22 Aug 2018 02:32:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-original-authentication-results:x-gm-message-state:from:to:cc :subject:date:message-id; bh=GNke+4p7Lu+SHndIr4sYMwH8plkTnxcGztrvWB/R6gY=; b=o7FJ99kLq+4l9QPmaUepxvGzRfk1v2vTJNdczOIqUcYsSXvN2kovMREmvUpeAClrdG /OMznLH8VY0d9lK6K5nmSP3gAYI2/RidsVkUNNlGvNXQHi0NADoDKAFMohMoYUPi72gk edR7J10twNbZtw5t9YY9XIeV6H7UueR0LTEJ87SNsD1Ufa8ilJrArue5v1svr8ip+I1x f/vbdF75D8kfvFslFEtM9eAD515NaNjqYlGQuVCrel247O5yrtAUiy5UFmcqlvIIEHY2 kXFkk1fxGmBza4XIxp01cDrSgV2pFlFw8WlY4Urju3XtC1NgF0GGTPlFHqpryHLHDfQA Uqpg== X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of osalvador.vilardaga@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=osalvador.vilardaga@gmail.com X-Gm-Message-State: APzg51AjIKqmn2t5vXeDkzlWCTLamtAO4ZHi31eAYt4PFyBStIOcp0pe U2Lv6Xt5WYt8ne4KWQEk0NvXbqncUGhDVsPrlnGVvYYy/ntSqKd6acyJHO10MYM4k8wi5IzY+Et tt4ILIrnR7Ip/NdOQyZaJ9iCHa3vG6Vzxr2vmHk/YOYDs08G2M6Cw1WFGFsbw2qHMHlojaX6H0s kex60xQguetcATG0Ks+b88PnuON3qFOkknpLK6gA3wx44r7AgBFkjltY8eMuN6AqmfAPie2C+yN MbaCCxlp4yE2F8b7wvMvs+cqCIp+L3DuQcamDqZonNvdc5C+wVTIrWh51CR78IvWtrMI8r6e7Lp L9JOfMC0Vd8/kkSx4+lg8lnu97N561QLayT7Z62y+LmaUawYM6aBTQCrTaIJaQZ+ZZvBwLPEog= = X-Received: by 2002:a1c:230f:: with SMTP id j15-v6mr1856256wmj.124.1534930353236; Wed, 22 Aug 2018 02:32:33 -0700 (PDT) X-Received: by 2002:a1c:230f:: with SMTP id j15-v6mr1856216wmj.124.1534930352361; Wed, 22 Aug 2018 02:32:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1534930352; cv=none; d=google.com; s=arc-20160816; b=Zv7wWrMh4XbJeGNy+KGMs7tiqZkSVsWnDRoZQjFxnhyUVonEZoTl+CP7SUr3eBRw8b z866pnz4Pzl1ug8UtS5se00j5lNxbFyn6oAVMP8/7i56bFmsVrdyQhypnro+ahtGvLzB T+IKPdBWTqnsvVTbzplGvVabLVDJ+4Nw5wOr4uB7cy+XLn5WPgyhmTF3w0PLnBLO/lwc nnODBYWchLph6pPxyHY3a3yXO34dy7ye3Y6Mq1HkwgiQgGHUIb7kejUtCaivfIPQUE+r gI/LTKK0de78nUy0830tdRdTcS0YqAGkhdp64SF35agKdi6MZsLt/oZCEM64DCg2AhUo L5+A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=message-id:date:subject:cc:to:from:arc-authentication-results; bh=GNke+4p7Lu+SHndIr4sYMwH8plkTnxcGztrvWB/R6gY=; b=0YHYUtzycrwDMNwwErw65XfAmCweEOGUwrHNc2BuBNtCGbneNYfPDgY2WGH82Eu7M6 02cYK+o2GpPeVlvCxib/CEFdlY8wZhjcFvr9+KYgYJw6XkWadGE+w5EeMVmQ17OoeXhA J0P7PXmm6gFu3vKhl0+LmWWj6t028Aj7SkzdvMoQwKYkA7NrJ9g+klvDT51APeqkSByT M0yX8mzJp5RLHoHk6B4ej+OkJELDGGVyKd7KRQqB9l8EUpnPhILNom53wLRCYsEFsXtV 265tH0MkoRzHM1Aw0qtVTftKusRif+hxVKQVMpr4jcPjKyUDCHgKDHrX1wPVyuMYtP+D mRIA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of osalvador.vilardaga@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=osalvador.vilardaga@gmail.com Received: from mail-sor-f41.google.com (mail-sor-f41.google.com. [209.85.220.41]) by mx.google.com with SMTPS id v17-v6sor386721wrd.55.2018.08.22.02.32.32 for <linux-mm@kvack.org> (Google Transport Security); Wed, 22 Aug 2018 02:32:32 -0700 (PDT) Received-SPF: pass (google.com: domain of osalvador.vilardaga@gmail.com designates 209.85.220.41 as permitted sender) client-ip=209.85.220.41; Authentication-Results: mx.google.com; spf=pass (google.com: domain of osalvador.vilardaga@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=osalvador.vilardaga@gmail.com X-Google-Smtp-Source: ANB0VdbvJSNj1cvv7YHcpuCJmMYc+NxoxnYmiiOhDVLUID3SQ1WZJKQWRmhwNzeRmjPlJ8mytJfuOA== X-Received: by 2002:a5d:4ac1:: with SMTP id y1-v6mr6047615wrs.248.1534930352021; Wed, 22 Aug 2018 02:32:32 -0700 (PDT) Received: from techadventures.net (techadventures.net. [62.201.165.239]) by smtp.gmail.com with ESMTPSA id r30-v6sm1879318wrc.90.2018.08.22.02.32.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 Aug 2018 02:32:31 -0700 (PDT) Received: from d104.suse.de (nat.nue.novell.com [195.135.221.2]) by techadventures.net (Postfix) with ESMTPA id B152F124A08; Wed, 22 Aug 2018 11:32:30 +0200 (CEST) From: Oscar Salvador <osalvador@techadventures.net> To: akpm@linux-foundation.org Cc: mhocko@suse.com, dan.j.williams@intel.com, malat@debian.org, david@redhat.com, Pavel.Tatashin@microsoft.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, Oscar Salvador <osalvador@suse.de> Subject: [RFC PATCH 0/5] Clean up node_states_check_changes_online/offline Date: Wed, 22 Aug 2018 11:32:21 +0200 Message-Id: <20180822093226.25987-1-osalvador@techadventures.net> X-Mailer: git-send-email 2.13.6 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000002, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: <linux-mm.kvack.org> X-Virus-Scanned: ClamAV using ClamSMTP |
Series |
Clean up node_states_check_changes_online/offline
|
expand
|
From: Oscar Salvador <osalvador@suse.de> This patchset clean ups node_states_check_changes_online/offline functions together with node_states_set/clear_node functions. The main reason behind this patchset is that currently, these functions are suboptimal and confusing. For example, they contain wrong statements like: if (N_MEMORY == N_NORMAL_MEMORY) if (N_MEMORY =! N_NORMAL_MEMORY) if (N_MEMORY != N_HIGH_MEMORY) if (N_MEMORY == N_HIGH_MEMORY) At least, I could not find anywhere where N_NORMAL_MEMORY gets assigned to N_MEMORY, or the other way around. Neither for the N_HIGH_MEMORY case. My rough guess is that all that was meant to compare N_NORMAL_MEMORY to N_HIGH_MEMORY, to see if we were on CONFIG_HIGHMEM systems. This went unnoticed because the if statements never got triggered, so they were always silent. For instance, let us take a look at node_states_clear_node ... if ((N_MEMORY != N_NORMAL_MEMORY) && (arg->status_change_nid_high >= 0)) node_clear_state(node, N_HIGH_MEMORY); if ((N_MEMORY != N_HIGH_MEMORY) && (arg->status_change_nid >= 0)) node_clear_state(node, N_MEMORY); ... Since N_MEMORY will never be equal to neither N_HIGH_MEMORY nor N_NORMAL_MEMORY, this justs proceeds normally. Another case is node_states_check_changes_offline: ... zone_last = ZONE_HIGHMEM; if (N_MEMORY == N_HIGH_MEMORY) zone_last = ZONE_MOVABLE; ... Since N_MEMORY will never be equal to N_HIGH_MEMORY, zone_last will never be set to ZONE_MOVABLE. But this is fine as the code works without that. After I found all this, I tried to re-write the code in a more understandable way, and I got rid of these confusing parts on the way. Another reason for this patchset is that there are some functions that are called unconditionally when they should only be called under certain conditions. That is the case for: - node_states_set_node()->node_set_state(node, N_MEMORY) * node_states_set_node() gets called whenever we online pages, so we end up calling node_set_state(node, N_MEMORY) everytime. To avoid this, we should check if the node is already in node_state[N_MEMORY]. - node_states_set_node()->node_set_state(node, N_HIGH_MEMORY) * On !CONFIG_HIGH_MEMORY, N_HIGH_MEMORY == N_NORMAL_MEMORY, but the current code sets: status_change_nid_high = status_change_nid_normal This means that we will call node_set_state(node, N_NORMAL_MEMORY) twice. The fix here is to set status_change_nid_normal = -1 on such systems, so we skip the second call. I tried it out on x86_64 so far and everything worked. But I would like to get feedback on this since I could be missing something. Oscar Salvador (5): mm/memory_hotplug: Spare unnecessary calls to node_set_state mm/memory_hotplug: Avoid node_set/clear_state(N_HIGH_MEMORY) when !CONFIG_HIGHMEM mm/memory_hotplug: Simplify node_states_check_changes_online mm/memory_hotplug: Tidy up node_states_clear_node mm/memory_hotplug: Simplify node_states_check_changes_offline mm/memory_hotplug.c | 146 +++++++++++++++++++++------------------------------- 1 file changed, 60 insertions(+), 86 deletions(-)