Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp1397831ybb; Thu, 9 Apr 2020 01:01:45 -0700 (PDT) X-Google-Smtp-Source: APiQypIrFOP0SAzJyc2CcX4enEKbZDLVm7U/ELM0wikhHlfnaueQd54D2k07qtDZSD6GbceMsHRj X-Received: by 2002:a4a:3f19:: with SMTP id e25mr9047357ooa.67.1586419305218; Thu, 09 Apr 2020 01:01:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1586419305; cv=none; d=google.com; s=arc-20160816; b=sBK8sUVDUKJ8Va5AYMvYGSrHHqv88RhgTAUkXUVJ0i3cp2TDda9XghmdmG7Eu1FtAJ P1iATHekzi+UW79A5wgrGIawtljnXxDTbEi2Ho5AvviE9oOrUFj/97Z1C+LT8scKwsij OC9nmkn60YTa3E6N4ZqbymkpoO66/29sx8xDvQNmu7o14rO1ZyanX10IKFPJ5WrNwWtR fKDlfMITo7xv+j3wpdNwNnPRBeSas60eUzhaQ9lx69q5bMuIU+sUoT2SaKvZkTEWLs+b I5qLT1w8NKZsprVaxTHkuI/0c7dyGrodfZ3Ghh+CP8AW8XunbX7BFW99n07Ll/4f4WhG Ik7g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=7aTkrJXqv2ZbDFk7CEzBnxc6D6u1o+Ia6P0f4mFbFV8=; b=TmIdqWqCdwhM1yEifFTWQwUcepcZ4c3Qn2YaiK2FslCWijSDJg8CHxR00QgiarSzZo /qrMBjvVXqatrMh4VRNZC8nexoS1/Q9+4fK4/cg9LdFntzg6bAQJxVBhQoVxh+oQ4VX3 EBtpIvhmSvNJi8o0cBthvEy9GfGJljbKF97p+nYj3oXMg1Hp16+lVFJ+ha/XrhVHW0Z9 8+fKnjh7riZWgbT1uJsfXy2laZMro0lAWNfSytIFeMkadl75CFo+KCjQO3rcsnhdRHL6 joYlBs0Ig6YgIzQdcPkF8DthOOr+hHds0HWQ/o1ktN0f8ckQtabWWrSiylqZTsXROD5U eC5A== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id s25si758856otr.72.2020.04.09.01.01.29; Thu, 09 Apr 2020 01:01:45 -0700 (PDT) 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726470AbgDIH7b (ORCPT + 99 others); Thu, 9 Apr 2020 03:59:31 -0400 Received: from mail-wm1-f68.google.com ([209.85.128.68]:53703 "EHLO mail-wm1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725828AbgDIH7b (ORCPT ); Thu, 9 Apr 2020 03:59:31 -0400 Received: by mail-wm1-f68.google.com with SMTP id d77so2911314wmd.3 for ; Thu, 09 Apr 2020 00:59:30 -0700 (PDT) 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; bh=7aTkrJXqv2ZbDFk7CEzBnxc6D6u1o+Ia6P0f4mFbFV8=; b=RtBySiUDfA2Rebd9Q4iBdX15N5MYedefaju9wr4+DD+nv9V5/x5UqyfmWwkWuC1C33 4HMsuIIozI0v4xQvQJ3MsSbMi8n5EJgZIr9gnA0YB6bs4yA/PfeeRoQCB3VLaWrMnNJg RbxATp88Vek9JZJZyuKYaWocI7LxpnV7NIYk1HKxhOS/jrgaQSWcr4kedJDfGNajUyO5 N7H/LkzoSR2u6ZXpHMHZBip/qDMA9u96yanq8hm0ZiyDOiNiLe+SgdlDekhpZa54j/Cj HoCeuWRWaedDvpHW3Jgnb99ifcKbyTX52FNxh3u2t+LiwMZJ5V8dLTME8Wo+OWBjedZH PPaw== X-Gm-Message-State: AGi0Pubgn2xVbf4Ykv2r6qjfhSgmpnT+NY8YLXAEM5CYCmYt14kTHITJ fdq004jmMmqp4XllVzo2+iM= X-Received: by 2002:a7b:c8cd:: with SMTP id f13mr9019734wml.181.1586419170075; Thu, 09 Apr 2020 00:59:30 -0700 (PDT) Received: from localhost (ip-37-188-180-223.eurotel.cz. [37.188.180.223]) by smtp.gmail.com with ESMTPSA id b82sm2901790wmh.1.2020.04.09.00.59.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 09 Apr 2020 00:59:28 -0700 (PDT) Date: Thu, 9 Apr 2020 09:59:27 +0200 From: Michal Hocko To: Michael Ellerman Cc: David Hildenbrand , linux-kernel@vger.kernel.org, linux-mm@kvack.org, linuxppc-dev@lists.ozlabs.org, Nathan Fontenot , Benjamin Herrenschmidt , Paul Mackerras , Andrew Morton , Oscar Salvador , Baoquan He , Wei Yang Subject: Re: [PATCH v1 1/2] powerpc/pseries/hotplug-memory: stop checking is_mem_section_removable() Message-ID: <20200409075927.GC18386@dhcp22.suse.cz> References: <20200407135416.24093-1-david@redhat.com> <20200407135416.24093-2-david@redhat.com> <87sghdjf1y.fsf@mpe.ellerman.id.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87sghdjf1y.fsf@mpe.ellerman.id.au> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu 09-04-20 17:26:01, Michael Ellerman wrote: > David Hildenbrand writes: > > > In commit 53cdc1cb29e8 ("drivers/base/memory.c: indicate all memory > > blocks as removable"), the user space interface to compute whether a memory > > block can be offlined (exposed via > > /sys/devices/system/memory/memoryX/removable) has effectively been > > deprecated. We want to remove the leftovers of the kernel implementation. > > > > When offlining a memory block (mm/memory_hotplug.c:__offline_pages()), > > we'll start by: > > 1. Testing if it contains any holes, and reject if so > > 2. Testing if pages belong to different zones, and reject if so > > 3. Isolating the page range, checking if it contains any unmovable pages > > > > Using is_mem_section_removable() before trying to offline is not only racy, > > it can easily result in false positives/negatives. Let's stop manually > > checking is_mem_section_removable(), and let device_offline() handle it > > completely instead. We can remove the racy is_mem_section_removable() > > implementation next. > > > > We now take more locks (e.g., memory hotplug lock when offlining and the > > zone lock when isolating), but maybe we should optimize that > > implementation instead if this ever becomes a real problem (after all, > > memory unplug is already an expensive operation). We started using > > is_mem_section_removable() in commit 51925fb3c5c9 ("powerpc/pseries: > > Implement memory hotplug remove in the kernel"), with the initial > > hotremove support of lmbs. > > It's also not very pretty in dmesg. > > Before: > > pseries-hotplug-mem: Attempting to hot-add 10 LMB(s) > pseries-hotplug-mem: Memory hot-add failed, removing any added LMBs > dlpar: Could not handle DLPAR request "memory add count 10" Yeah, there is more output but isn't that useful? Or put it differently what is the actual problem from having those messages in the kernel log? From the below you can clearly tell that there are kernel allocations which prevent hot remove from happening. If the overall size of the debugging output is a concern then we can think of a way to reduce it. E.g. once you have a couple of pages reported then all others from the same block are likely not interesting much. -- Michal Hocko SUSE Labs