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=-2.5 required=3.0 tests=MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 60164C33CB1 for ; Fri, 17 Jan 2020 11:33:57 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 2AE1A2073A for ; Fri, 17 Jan 2020 11:33:57 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2AE1A2073A Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id B61016B035F; Fri, 17 Jan 2020 06:33:56 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id B11A96B0360; Fri, 17 Jan 2020 06:33:56 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A01696B0361; Fri, 17 Jan 2020 06:33:56 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0178.hostedemail.com [216.40.44.178]) by kanga.kvack.org (Postfix) with ESMTP id 86FD86B035F for ; Fri, 17 Jan 2020 06:33:56 -0500 (EST) Received: from smtpin02.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with SMTP id 3C17E8248076 for ; Fri, 17 Jan 2020 11:33:56 +0000 (UTC) X-FDA: 76386916872.02.pipe80_79a3cd4d7dc54 X-HE-Tag: pipe80_79a3cd4d7dc54 X-Filterd-Recvd-Size: 4003 Received: from mail-wm1-f66.google.com (mail-wm1-f66.google.com [209.85.128.66]) by imf39.hostedemail.com (Postfix) with ESMTP for ; Fri, 17 Jan 2020 11:33:55 +0000 (UTC) Received: by mail-wm1-f66.google.com with SMTP id d139so9298301wmd.0 for ; Fri, 17 Jan 2020 03:33:55 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=pS6tGirNA5l2St8BRcYo+tvzqyq6o10cg8yYZAWBJ5A=; b=t1pe1GPWycrKDz4CPwplsBgckAUdVkXYzWjlMi/g11MA88Uqzyhf7rOwRXyUTvYcxf YwGg2MYDyk/uvJgAHEyFsp903Cy9VjVSCivJWmiRtT1zCkSD27yIFL6PAtvJtaWhOfUK 8IHj713E9QUBdguZbmIUfYyWCXafR7zhJ/FrvbCT+nWMeIPSnNMXxMi2Oaq9/Yk51Rrk 3GkQGgaxAgNRANmQ2V45/MCqptG2wKqMUIRym3JZAPj/WZ55yB19iO/WtNKucRSUxpfW i7Tk5KCaq1H94zcnv73maiy/uoLslZez8Zfrw0epd22XWhmehQ1BQrtEPIska1Eiicf1 J6+g== X-Gm-Message-State: APjAAAXDJNQrWkMXTHrHtHL/+WLEPVR/EtnS4NA8NJ8ifLsnQFyJSmAz kQU+1g7VLHjl3OYEexFcvZA= X-Google-Smtp-Source: APXvYqxYYwk3Ieuhh1JlXLR3/Y6vU+ft9LXH9FfnZA5oIVuyDDQ22H4//+d0cssKHwtPEfLC9wp91g== X-Received: by 2002:a05:600c:228f:: with SMTP id 15mr4294224wmf.56.1579260834716; Fri, 17 Jan 2020 03:33:54 -0800 (PST) Received: from localhost (prg-ext-pat.suse.com. [213.151.95.130]) by smtp.gmail.com with ESMTPSA id t12sm33450532wrs.96.2020.01.17.03.33.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 17 Jan 2020 03:33:54 -0800 (PST) Date: Fri, 17 Jan 2020 12:33:53 +0100 From: Michal Hocko To: David Hildenbrand Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, Benjamin Herrenschmidt , Paul Mackerras , Michael Ellerman , Greg Kroah-Hartman , "Rafael J. Wysocki" , Andrew Morton , Leonardo Bras , Nathan Lynch , Allison Randal , Nathan Fontenot , Thomas Gleixner , Dan Williams , Stephen Rothwell , Anshuman Khandual , lantianyu1986@gmail.com, linuxppc-dev@lists.ozlabs.org Subject: Re: [PATCH RFC v1] mm: is_mem_section_removable() overhaul Message-ID: <20200117113353.GT19428@dhcp22.suse.cz> References: <20200117105759.27905-1-david@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200117105759.27905-1-david@redhat.com> User-Agent: Mutt/1.12.2 (2019-09-21) 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 Fri 17-01-20 11:57:59, David Hildenbrand wrote: > Let's refactor that code. We want to check if we can offline memory > blocks. Add a new function is_mem_section_offlineable() for that and > make it call is_mem_section_offlineable() for each contained section. > Within is_mem_section_offlineable(), add some more sanity checks and > directly bail out if the section contains holes or if it spans multiple > zones. I didn't read the patch (yet) but I am wondering. If we want to touch this code, can we simply always return true there? I mean whoever depends on this check is racy and the failure can happen even after the sysfs says good to go, right? The check is essentially as expensive as calling the offlining code itself. So the only usecase I can think of is a dumb driver to crawl over blocks and check which is removable and try to hotremove it. But just trying to offline one block after another is essentially going to achieve the same. Or does anybody see any reasonable usecase that would break if we did that unconditional behavior? -- Michal Hocko SUSE Labs