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=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 7511EC32771 for ; Wed, 22 Jan 2020 20:51:43 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 2767C24676 for ; Wed, 22 Jan 2020 20:51:43 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=intel-com.20150623.gappssmtp.com header.i=@intel-com.20150623.gappssmtp.com header.b="KTTat97k" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2767C24676 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id B88656B0003; Wed, 22 Jan 2020 15:51:42 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id B38DB6B0005; Wed, 22 Jan 2020 15:51:42 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A28016B0006; Wed, 22 Jan 2020 15:51:42 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0072.hostedemail.com [216.40.44.72]) by kanga.kvack.org (Postfix) with ESMTP id 8DB726B0003 for ; Wed, 22 Jan 2020 15:51:42 -0500 (EST) Received: from smtpin20.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with SMTP id 50F8B2C04 for ; Wed, 22 Jan 2020 20:51:42 +0000 (UTC) X-FDA: 76406466444.20.nose34_2bef5757c2602 X-HE-Tag: nose34_2bef5757c2602 X-Filterd-Recvd-Size: 5509 Received: from mail-ot1-f66.google.com (mail-ot1-f66.google.com [209.85.210.66]) by imf12.hostedemail.com (Postfix) with ESMTP for ; Wed, 22 Jan 2020 20:51:41 +0000 (UTC) Received: by mail-ot1-f66.google.com with SMTP id z9so652957oth.5 for ; Wed, 22 Jan 2020 12:51:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sIoRmzHYTdpp+dqkgtOBAN7ncVHrjk3h+URxl69sPsU=; b=KTTat97kNuZvEUjvtDsTDzjPFUlG4KFZhZl+L6EC2PUatXH7uO7Fwgd4s6J58cZhN5 gFfWgSMR9b8GP4PDwfSvlZvOzvYU7a8/5bet4UUOtnOoJDkm3Z2dEBjnwzrocD017Rf4 Fi2e7cyAJ7RFuyunUhht5zqTEOrcAgKo8OuGKuibOv6MaxPQI6yH2gj1cQL4WVe9JLVb 9suPZhEO9ZuVE+dk4q7RjQzz3bYS71BwsbbExkx8V/pfSsmMhU+Bm7J8DfdFJ7XNpM1K jE32TDYypZKfW0hhy389pFV0hc9k9hp2LMRDf2xco+fNCjphLs7c5CjBg9cy3okaphV1 T2qw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sIoRmzHYTdpp+dqkgtOBAN7ncVHrjk3h+URxl69sPsU=; b=B7/WeICRIAocLyBchPG1wwng14VutwqE7PmYWgbinz0k3IArJ8fGEyWL3O58Q7RRwR VxlzqNXTzrxYN8zJoj4c9CSTazB8PNHhxcOdxk/9JuFoNoMBt+tYpPBH3QJDRsS+XhKu Zsm6wpArYzur4SLqzrO9SmuflmidCljZMBRli+OHCg9yoGK+WXS3b56I0Q4rXSkZKxB3 GcnVJP83FOl8e3gbMLSIYSPmwEAXkpmN6tB1umgds7Witz2JS8RBZOiQxsZlKHAHWz7b uSuGqkt3FzuS1qKrlilwpG1sLtw571r2aEiFo7tobbBTPjeRhUQXP92fq4a7MB+yPGL9 fI9g== X-Gm-Message-State: APjAAAXn4Lyxv3cJOHfUdkpLsQ5rPStBR+ymxRYvdVR5VliBRBTM7W3l SiDuPb6tlDnPbPL4f/6hZna3obP7x/t6V3bSJuL8Mg== X-Google-Smtp-Source: APXvYqw6v4/RiaBhyLB4WHjODSz1dAkLJtJwJGKbGaMd/yQZSfCSqgwxWgXkA77oncy7GPixkDTN6S48x5VwRtTkUVA= X-Received: by 2002:a05:6830:4d9:: with SMTP id s25mr8907122otd.171.1579726300916; Wed, 22 Jan 2020 12:51:40 -0800 (PST) MIME-Version: 1.0 References: <20200121120714.GJ29276@dhcp22.suse.cz> <20200122104230.GU29276@dhcp22.suse.cz> <98b6c208-b4dd-9052-43f6-543068c649cc@redhat.com> <816ddd66-c90b-76f1-f4a0-72fe41263edd@redhat.com> <20200122164618.GY29276@dhcp22.suse.cz> <626d344e-8243-c161-cd07-ed1276eba73d@redhat.com> <20200122183809.GB29276@dhcp22.suse.cz> <20200122190903.GD29276@dhcp22.suse.cz> In-Reply-To: <20200122190903.GD29276@dhcp22.suse.cz> From: Dan Williams Date: Wed, 22 Jan 2020 12:51:28 -0800 Message-ID: Subject: Re: [PATCH RFC v1] mm: is_mem_section_removable() overhaul To: Michal Hocko Cc: David Hildenbrand , Linux Kernel Mailing List , Linux MM , Benjamin Herrenschmidt , Paul Mackerras , Michael Ellerman , Greg Kroah-Hartman , "Rafael J. Wysocki" , Andrew Morton , Leonardo Bras , Nathan Lynch , Allison Randal , Nathan Fontenot , Thomas Gleixner , Stephen Rothwell , Anshuman Khandual , lantianyu1986@gmail.com, linuxppc-dev Content-Type: text/plain; charset="UTF-8" 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: On Wed, Jan 22, 2020 at 11:09 AM Michal Hocko wrote: > > On Wed 22-01-20 19:46:15, David Hildenbrand wrote: > > On 22.01.20 19:38, Michal Hocko wrote: > [...] > > > How exactly is check + offline more optimal then offline which makes > > > check as its first step? I will get to your later points after this is > > > clarified. > > > > Scanning (almost) lockless is more efficient than bouncing back and > > forth with the device_hotplug_lock, mem_hotplug_lock, cpu_hotplug_lock > > and zone locks - as far as I understand. > > All but the zone lock shouldn't be really contended and as such > shouldn't cause any troubles. zone->lock really depends on the page > allocator usage of course. But as soon as we have a contention then it > is just more likely that the result is less reliable. > > I would be also really curious about how much actual time could be saved > by this - some real numbers - because hotplug operations shouldn't > happen so often that this would stand out. At least that is my > understanding. > > > And as far as I understood, that was the whole reason of the original > > commit. > > Well, I have my doubts but it might be just me and I might be wrong. My > experience from a large part of the memory hotplug functionality is that > it was driven by a good intention but without a due diligence to think > behind the most obvious usecase. Having a removable flag on the memblock > sounds like a neat idea of course. But an inherently racy flag is just > borderline useful. > > Anyway, I will stop at this moment and wait for real usecases. ...that and practical numbers showing that optimizing an interface that can at best give rough estimate answers is worth the code change.