From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk0-f199.google.com (mail-qk0-f199.google.com [209.85.220.199]) by kanga.kvack.org (Postfix) with ESMTP id EDDF86B0003 for ; Wed, 8 Aug 2018 03:51:54 -0400 (EDT) Received: by mail-qk0-f199.google.com with SMTP id 17-v6so1465827qkz.15 for ; Wed, 08 Aug 2018 00:51:54 -0700 (PDT) Received: from mx1.redhat.com (mx3-rdu2.redhat.com. [66.187.233.73]) by mx.google.com with ESMTPS id 40-v6si416804qku.277.2018.08.08.00.51.54 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Aug 2018 00:51:54 -0700 (PDT) Subject: Re: [RFC PATCH 2/3] mm/memory_hotplug: Create __shrink_pages and move it to offline_pages References: <20180807133757.18352-1-osalvador@techadventures.net> <20180807133757.18352-3-osalvador@techadventures.net> <20180807135221.GA3301@redhat.com> <20180807204834.GA6844@techadventures.net> <20180807221345.GD3301@redhat.com> <20180808073835.GA9568@techadventures.net> From: David Hildenbrand Message-ID: <24da07b9-5e06-af1d-42d3-c663eade16ea@redhat.com> Date: Wed, 8 Aug 2018 09:51:50 +0200 MIME-Version: 1.0 In-Reply-To: <20180808073835.GA9568@techadventures.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Oscar Salvador , Jerome Glisse Cc: akpm@linux-foundation.org, mhocko@suse.com, dan.j.williams@intel.com, pasha.tatashin@oracle.com, yasu.isimatu@gmail.com, logang@deltatee.com, dave.jiang@intel.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Oscar Salvador On 08.08.2018 09:38, Oscar Salvador wrote: > On Tue, Aug 07, 2018 at 06:13:45PM -0400, Jerome Glisse wrote: >>> And since we know for sure that memhotplug-code cannot call it with ZONE_DEVICE, >>> I think this can be done easily. >> >> This might change down road but for now this is correct. They are >> talks to enumerate device memory through standard platform mechanisms >> and thus the kernel might see new types of resources down the road and >> maybe we will want to hotplug them directly from regular hotplug path >> as ZONE_DEVICE (lot of hypothetical at this point ;)). > > Well, I think that if that happens this whole thing will become > much easier, since we will not have several paths for doing the same thing. > > Another thing that I realized is that while we want to move all operation-pages > from remove_memory() path to offline_pages(), this can get tricky. > > Unless I am missing something, the devices from HMM and devm are not being registered > against "memory_subsys" struct, and so, they never get to call memory_subsys_offline() > and so offline_pages(). > > Which means that we would have to call __remove_zone() from those paths. > But this alone will not work. > > find_smallest/biggest_section_pfn are two functions that are being called from > > shrink_pgdat_span > and > shrink_zone_span > > to adjust zone_first_pfn/node_first_pfn and the spanned pages. > > Currently, find_smallest/biggest_section_pfn checks for the secion to be valid, > and this is fine since we are removing those sections from the remove_memory path. > > But if we want to move __remove_zone() to offline_pages(), we have to use > online_section() instead of valid_section(). > > This is all fine from offline_pages because the sections get offlined in: > > __offline_pages > offline_isolated_pages > offline_isolated_pages_cb > __offline_isolated_pages > offline_mem_sections > > > But this does not happen in HMM/devm path. > > I am pretty sure this is a dumb question, but why HMM/devm path > do not call online_pages/offline_pages? I think mainly because onlining/offlining (wild guesses) - calls memory notifiers - works with memory blocks (and does some more things not applicable to ZONE_DEVICE memory) > > Thanks > -- Thanks, David / dhildenb