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.6 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,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 AFBF0C33CB1 for ; Tue, 14 Jan 2020 09:51:02 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 8780224672 for ; Tue, 14 Jan 2020 09:51:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1578995462; bh=zC495FTuIWw6tEjC1ujZCfUrV5RJEqDi+FjUGjYqLxg=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=T4y30Fkxix1qejtI4fUjuXcMya8994LiD40HvFnBiJdmYXzKYHIIps3kJglZNcCt6 GDDl0DeYdwDLkVMF6TZjx8GAb/8nYTOAERVbY0Qy6wW/Z2cltKhdEFZ746hNhCvO6Z YWe5fPcL230xUlAolbWWJwi8FvtlUZ4S/Y/9FLkI= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729106AbgANJvB (ORCPT ); Tue, 14 Jan 2020 04:51:01 -0500 Received: from mail-wr1-f65.google.com ([209.85.221.65]:38613 "EHLO mail-wr1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725842AbgANJvA (ORCPT ); Tue, 14 Jan 2020 04:51:00 -0500 Received: by mail-wr1-f65.google.com with SMTP id y17so11477473wrh.5; Tue, 14 Jan 2020 01:50:59 -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=pEjFsFpCypBmbTAAbsMBZocao2aRdb0v8F3qtUDClnU=; b=mPUrjxnJuhzLL6qO+w/054KsvJgIDO7sUnVlRYpRV7Mz3vliCbrPKwx8aDVPAZJwmf vmTlJvYItaH4e/DXzOhZBf2VNHEdF/+YgFMWhVRbeo2EWJn/rgySIkedTegRC8lUsrHM Xas+L3urUcUoXwKIYThrnO3VfxwcbfTVrV9Yf1X8udgtp+90I3Rw5OBraQ39GZSjBOTg DPJUUofDdOfRJIyaNTkxiSsMUGLZTWqtoSvdxBCyr5kC5CUDTAdkQvlF09fqKqPaTy+K nwOWZ/2k+EBykmOvN2li4SJjwufyTcw30TTc8qlvZulpKCm6Jo6FL7ezU6K8fOg9UhM2 Dk3Q== X-Gm-Message-State: APjAAAXUrFzL++3bRG7fzGyEzMXlBWVhRj+GDhYA0LufIuWaa6EgN/2E luSq5RdmkQKJxQp678TkwMc= X-Google-Smtp-Source: APXvYqzcd9TQA5n6FKsfqJRldrVd7OL4sZZDEncBCpJwnaTi+pv49H3QMRWm9zPqXoTATkShHQWBlg== X-Received: by 2002:adf:a746:: with SMTP id e6mr24863095wrd.329.1578995459210; Tue, 14 Jan 2020 01:50:59 -0800 (PST) Received: from localhost (prg-ext-pat.suse.com. [213.151.95.130]) by smtp.gmail.com with ESMTPSA id b10sm19428113wrt.90.2020.01.14.01.50.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 14 Jan 2020 01:50:58 -0800 (PST) Date: Tue, 14 Jan 2020 10:50:57 +0100 From: Michal Hocko To: Tianyu Lan Cc: David Hildenbrand , "lantianyu1986@gmail.com" , KY Srinivasan , Haiyang Zhang , Stephen Hemminger , "sashal@kernel.org" , "akpm@linux-foundation.org" , Michael Kelley , "linux-hyperv@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , vkuznets , "eric.devolder@oracle.com" , "vbabka@suse.cz" , "osalvador@suse.de" , Pasha Tatashin , "rppt@linux.ibm.com" Subject: Re: [EXTERNAL] Re: [RFC PATCH V2 2/10] mm: expose is_mem_section_removable() symbol Message-ID: <20200114095057.GK19428@dhcp22.suse.cz> References: <20200107130950.2983-1-Tianyu.Lan@microsoft.com> <20200107130950.2983-3-Tianyu.Lan@microsoft.com> <20200107133623.GJ32178@dhcp22.suse.cz> <99a6db0c-6d73-d982-58b3-7a0172748ae4@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.2 (2019-09-21) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon 13-01-20 14:49:38, Tianyu Lan wrote: > Hi David & Michal: > Thanks for your review. Some memory blocks are not suitable for hot-plug. > If not check memory block's removable, offline_pages() will report some failure error > e.g, "failed due to memory holes" and "failure to isolate range". I think the check maybe > added into offline_and_remove_memory()? This may help to not create/expose a new > interface to do such check in module. Why is a log message a problem in the first place. The operation has failed afterall. Does the driver try to offline an arbitrary memory? Could you describe your usecase in more details please? -- Michal Hocko SUSE Labs