Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp3257594imm; Fri, 10 Aug 2018 06:28:36 -0700 (PDT) X-Google-Smtp-Source: AA+uWPxXF2Iy1kagATlGye9y+NWuW7hLGCKVpjfCnh/PPrK51ggrf5YRXN+tkEL9PZZm+6OyPMw+ X-Received: by 2002:a63:6188:: with SMTP id v130-v6mr6532037pgb.100.1533907716277; Fri, 10 Aug 2018 06:28:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1533907716; cv=none; d=google.com; s=arc-20160816; b=IQeGrjI77SjEcG03AwffRwcBBofRF3Ijq7LJ37tCIXMT2XmDjkW1Lz1IHoPlaCbRXi tFI7WwqqQu7LWP5U6ztDL2NQ8TV0NQPudqFJVikqLSpkVzSV9avNNyaYrj3aU/jDeOYW 31PR1FyuI83eWhVKbD/Vf6zQ7U+jwqVp5XAqNEvQjprrjXIj9SZNN8QLlVkiZLt3tAYf gOSDpX2FghRgmTJQWS8uTokjH8hdqYgv/SnfK1AfGdhrDEmSwSbKQ0/zzbx7CzJ/c3vD RIA28fxTBk7eMAV50Q6h9LgOk8TnJZQ8Veeed9zB8FAP0E46W3h+OV9ZI+FfvpvXk1Jq YcXQ== 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:arc-authentication-results; bh=W2yIt/qGPXWK3q0X9XRyjbxCpJ2MDQOnbJJNJ4n89nE=; b=BBpPpYKTOtLhVz5Sz21gZ+GFhX9R17b3PlJy+DduklpJyU3bvKaRhAya6/AOCZkvv5 A0OWoYKjvWzpNtu0QWDtnyVbWdW5Hm7AaWO8rvxxS0sffW9wxv/tGiA2rOJ8KiidPCfm rBFoznWYm6oxNdNtYqBfwXrIzLH5Tr6w8ggZHCx8yO1hSxHmNctsiGYxKFRE5zXfisU9 v0MyvWkVSeRClyGpHLUsDCdwVJOohH0kQ99uqCH0OA7JmRSSbuH7/o+tJIzQ9F9vnGXk j2J0XSqBYLKCXURVd57HfT8Hj9EgyLhanMsPHB5lD40wrWF+eVcAZtF14tKR6BWPk0DY 0njA== 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 o3-v6si7728852pld.281.2018.08.10.06.28.20; Fri, 10 Aug 2018 06:28:36 -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 S1728017AbeHJPar (ORCPT + 99 others); Fri, 10 Aug 2018 11:30:47 -0400 Received: from mx2.suse.de ([195.135.220.15]:49584 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727563AbeHJPar (ORCPT ); Fri, 10 Aug 2018 11:30:47 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay1.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 728D8AFEF; Fri, 10 Aug 2018 13:00:56 +0000 (UTC) Date: Fri, 10 Aug 2018 15:00:52 +0200 From: Michal Hocko To: Rashmica Gupta Cc: Andrew Morton , toshi.kani@hpe.com, tglx@linutronix.de, bp@suse.de, brijesh.singh@amd.com, thomas.lendacky@amd.com, jglisse@redhat.com, gregkh@linuxfoundation.org, baiyaowei@cmss.chinamobile.com, dan.j.williams@intel.com, iamjoonsoo.kim@lge.com, Vlastimil Babka , malat@debian.org, Bjorn Helgaas , osalvador@techadventures.net, yasu.isimatu@gmail.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, Mike Rapoport Subject: Re: [PATCH v3] resource: Merge resources on a node when hot-adding memory Message-ID: <20180810130052.GC1644@dhcp22.suse.cz> References: <20180809025409.31552-1-rashmica.g@gmail.com> <20180809181224.0b7417e51215565dbda9f665@linux-foundation.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 Fri 10-08-18 16:55:40, Rashmica Gupta wrote: [...] > Most memory hotplug/hotremove seems to be block or section based, and > always adds and removes memory at the same place. Yes and that is hard wired to the memory hotplug code. It is not easy to make it work outside of section units restriction. So whatever your memtrace is doing and if it relies on subsection hotplug it cannot possibly work with the current code. I didn't get to review your patch but if it is only needed for an unmerged code I would rather incline to not merge it unless it is a clear win to the resource subsystem. A report from Oscar shows that this is not the case though. -- Michal Hocko SUSE Labs