Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp4026850yba; Tue, 7 May 2019 10:52:47 -0700 (PDT) X-Google-Smtp-Source: APXvYqyxNoqoz5w/TPlZuhhLnsa3qNnyJjkG58GteeQvltrLCITCc+7skt6AZ854eHCsNRFxDheI X-Received: by 2002:a17:902:b410:: with SMTP id x16mr28924661plr.174.1557251567273; Tue, 07 May 2019 10:52:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1557251567; cv=none; d=google.com; s=arc-20160816; b=RPXdnmtTOsnOB2am/oduAtaDDWotoTuyNna+4J7/R8tMoCxcV5bTeRlznEs62LXw0m gQuR6R472zVDvXPTbzzoSQSX8nNzP3wjqZ4jwnX0Usc+fY0260161saIJP+u7LxEHyb6 Jc7mgpm5Nbq/EpjZlQPv7N6AlyTV8vWHgi7bK02YAQrFDbMI2R19bbbP/W4P3H+1foK0 4ps5pPT2OLugRp7r8AJ3mdC0/vnnkZyVPhfFCCCTyhQ0fePWZn30iCQl1+zhRUdzaxBg /Ex0bgcmjHE07qz9tuOFcUMR8Eh4xhTkjaWMJG/4cOkze5y/wmwmU+6LLkiJaphyISCL P8MA== 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=QnhL1bOGuZyLGLf3CFAATtCCATwNRzLa5UD+kyH4DkY=; b=ATUh65DsxMslNjJgXtldfSI/EelTIwdKQkekohDMJ6hZWBHbNIa/UFgSBm9o6XP1Lg +rRxazrb4TadbrMAvIR4wve3EGPQ4C9zZ9NwanGbIfT8O3qezoNtZWA5YVvZbVVPeVR3 fR/HOwpO3DCeHxLH13j5etY4Z6CQPLNW6T59Au9Fd7qr9dS6/vg+S89XUCPfr7iIDnRK jA3jC+usXDmVOdTMElCIv443JVUfKoKkAKOqFbIQAFS7iJxR/F61XyOvkrQx8nR93Vfx SRtzz0Tbedp+AEB4iNCfhqJGAIxFT2+jBuTi+Jn7ZlmhEUa027G1dw79OHVV79e+AF90 kwZQ== 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 v22si18741976pff.62.2019.05.07.10.52.30; Tue, 07 May 2019 10:52:47 -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 S1726799AbfEGRvg (ORCPT + 99 others); Tue, 7 May 2019 13:51:36 -0400 Received: from mx2.suse.de ([195.135.220.15]:59226 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726448AbfEGRvg (ORCPT ); Tue, 7 May 2019 13:51:36 -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 26A7EAEF5; Tue, 7 May 2019 17:51:35 +0000 (UTC) Date: Tue, 7 May 2019 19:51:33 +0200 From: Michal Hocko To: Linus Torvalds Cc: Matthew Wilcox , Sasha Levin , Alexander Duyck , LKML , stable , Mikhail Zaslonko , Gerald Schaefer , Mikhail Gavrilov , Dave Hansen , Alexander Duyck , Pasha Tatashin , Martin Schwidefsky , Heiko Carstens , Andrew Morton , Sasha Levin , linux-mm Subject: Re: [PATCH AUTOSEL 4.14 62/95] mm, memory_hotplug: initialize struct pages for the full memory section Message-ID: <20190507175133.GV31017@dhcp22.suse.cz> References: <20190507053826.31622-1-sashal@kernel.org> <20190507053826.31622-62-sashal@kernel.org> <20190507170208.GF1747@sasha-vm> <20190507171806.GG1747@sasha-vm> <20190507173224.GS31017@dhcp22.suse.cz> <20190507173655.GA1403@bombadil.infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 Tue 07-05-19 10:43:31, Linus Torvalds wrote: > On Tue, May 7, 2019 at 10:36 AM Matthew Wilcox wrote: > > > > Can we do something with qemu? Is it flexible enough to hotplug memory > > at the right boundaries? > > It's not just the actual hotplugged memory, it's things like how the > e820 tables were laid out for the _regular_ non-hotplug stuff too, > iirc to get the cases where something didn't work out. > > I'm sure it *could* be emulated, and I'm sure some hotplug (and page > poison errors etc) testing in qemu would be lovely and presumably some > people do it, but all the cases so far have been about odd small > special cases that people didn't think of and didn't hit. I'm not sure > the qemu testing would think of them either.. Yes, this is exactly my point. It would be great to have those odd small special cases that we have met already available though. For a regression testing for them at least. -- Michal Hocko SUSE Labs