Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp6980721ybi; Thu, 1 Aug 2019 01:21:35 -0700 (PDT) X-Google-Smtp-Source: APXvYqxJVpnvluJlu/3qTkFDCUdES94X4JIhMyj7umPGsJG+IlZaZRCJRq06Wr8QBbbUqqQ6ePTN X-Received: by 2002:a63:9e56:: with SMTP id r22mr60988688pgo.221.1564647695629; Thu, 01 Aug 2019 01:21:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1564647695; cv=none; d=google.com; s=arc-20160816; b=KzplA0g+BqnpEtn7z2Xasq/b+UZOhiysB0DySGQgPHNVtf+6kNnEgvLlJfU+Qm0WZQ Zus9HE1HZNEzw4waPFdbFXI2ME+OPmx9cUYfSrBwWy/S8la0ULhTkeqCw4PFddRG8FAn CYgISFDwd3OLYL2tKwrTAOrck1fdv9TQLrHvu52WB2aoSCGSgWEeHrrx2EoWW1U7LSCE VE1uxhy214d+h2ezXHrhS7X5KdUoGPFoti0BIno+rp8hhcadrelRrzRQuHrBwj1hQuiG bonrUOzTmIjxfX7BlhoPJow5DDBoo725WOcSEkmDOuZXCftNyVWOTJ63h4pYvLmNYnI1 coTw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=zLvXsQ8HNdjBM+AzuizHneH7ApFl7WVGHvnSGmFW7Lg=; b=kU8qKbIsRTEegPJsb7V6WDjfZToUALEhk4gU+6R0XbToxFBnVpI2GA37DkVrWJu849 jQlg32F5NkbspDa5Ldw1q14W2GxKfWTChR1rWE7OsATobjSND1H51/X8itevdlHJamaI wIw+l7EZULIYoevL7qS/0uAWlj4k1xZTqbNXu2kZTNaWbr6fbMFMW08rsIF+jo52AUor xIBzCDt6UZ77AcMB1IdkkV/S4VyV4nyLF9iPYoXetkAYcK9m/5ux5oFt3rKgeVWqQoP1 3PUFJ4o/5xx/d+9/mWadNkdaeO+KPhZ9BQ95BjSTahoZG6fYOG2nJliZvAZTGkrO/3kx +ScQ== 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 l6si9934296pgp.391.2019.08.01.01.21.20; Thu, 01 Aug 2019 01:21:35 -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 S1730766AbfHAHYe (ORCPT + 99 others); Thu, 1 Aug 2019 03:24:34 -0400 Received: from mx2.suse.de ([195.135.220.15]:55588 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1729459AbfHAHYe (ORCPT ); Thu, 1 Aug 2019 03:24:34 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id C8CFDB022; Thu, 1 Aug 2019 07:24:32 +0000 (UTC) Date: Thu, 1 Aug 2019 09:24:30 +0200 From: Michal Hocko To: David Hildenbrand Cc: Rashmica Gupta , Oscar Salvador , Andrew Morton , Dan Williams , pasha.tatashin@soleen.com, Jonathan.Cameron@huawei.com, anshuman.khandual@arm.com, Vlastimil Babka , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 0/5] Allocate memmap from hotadded memory Message-ID: <20190801072430.GF11627@dhcp22.suse.cz> References: <2750c11a-524d-b248-060c-49e6b3eb8975@redhat.com> <20190626081516.GC30863@linux> <887b902e-063d-a857-d472-f6f69d954378@redhat.com> <9143f64391d11aa0f1988e78be9de7ff56e4b30b.camel@gmail.com> <20190702074806.GA26836@linux> <20190731120859.GJ9330@dhcp22.suse.cz> <4ddee0dd719abd50350f997b8089fa26f6004c0c.camel@gmail.com> <20190801071709.GE11627@dhcp22.suse.cz> <9bcbd574-7e23-5cfe-f633-646a085f935a@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9bcbd574-7e23-5cfe-f633-646a085f935a@redhat.com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu 01-08-19 09:18:47, David Hildenbrand wrote: > On 01.08.19 09:17, Michal Hocko wrote: > > On Thu 01-08-19 09:06:40, Rashmica Gupta wrote: > >> On Wed, 2019-07-31 at 14:08 +0200, Michal Hocko wrote: > >>> On Tue 02-07-19 18:52:01, Rashmica Gupta wrote: > >>> [...] > >>>>> 2) Why it was designed, what is the goal of the interface? > >>>>> 3) When it is supposed to be used? > >>>>> > >>>>> > >>>> There is a hardware debugging facility (htm) on some power chips. > >>>> To use > >>>> this you need a contiguous portion of memory for the output to be > >>>> dumped > >>>> to - and we obviously don't want this memory to be simultaneously > >>>> used by > >>>> the kernel. > >>> > >>> How much memory are we talking about here? Just curious. > >> > >> From what I've seen a couple of GB per node, so maybe 2-10GB total. > > > > OK, that is really a lot to keep around unused just in case the > > debugging is going to be used. > > > > I am still not sure the current approach of (ab)using memory hotplug is > > ideal. Sure there is some overlap but you shouldn't really need to > > offline the required memory range at all. All you need is to isolate the > > memory from any existing user and the page allocator. Have you checked > > alloc_contig_range? > > > > Rashmica mentioned somewhere in this thread that the virtual mapping > must not be in place, otherwise the HW might prefetch some of this > memory, leading to errors with memtrace (which checks that in HW). Does anything prevent from unmapping the pfn range from the direct mapping? -- Michal Hocko SUSE Labs