All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Hildenbrand <david@redhat.com>
To: Michal Hocko <mhocko@kernel.org>
Cc: Pavel Tatashin <pasha.tatashin@oracle.com>,
	Linux Memory Management List <linux-mm@kvack.org>,
	LKML <linux-kernel@vger.kernel.org>,
	gregkh@linuxfoundation.org, mingo@kernel.org,
	Andrew Morton <akpm@linux-foundation.org>,
	dan.j.williams@intel.com, jack@suse.cz, mawilcox@microsoft.com,
	jglisse@redhat.com, Souptick Joarder <jrdr.linux@gmail.com>,
	kirill.shutemov@linux.intel.com, Vlastimil Babka <vbabka@suse.cz>,
	osalvador@techadventures.net, yasu.isimatu@gmail.com,
	malat@debian.org, Mel Gorman <mgorman@suse.de>,
	iamjoonsoo.kim@lge.com
Subject: Re: [PATCH v1] mm: inititalize struct pages when adding a section
Date: Mon, 30 Jul 2018 17:03:27 +0200	[thread overview]
Message-ID: <0be90c23-e5a0-2628-c671-9923d8e45b0a@redhat.com> (raw)
In-Reply-To: <20180730145035.GY24267@dhcp22.suse.cz>

On 30.07.2018 16:50, Michal Hocko wrote:
> On Mon 30-07-18 16:42:27, David Hildenbrand wrote:
>> On 30.07.2018 16:10, Michal Hocko wrote:
>>> On Mon 30-07-18 15:51:45, David Hildenbrand wrote:
>>>> On 30.07.2018 15:30, Pavel Tatashin wrote:
>>> [...]
>>>>> Hi David,
>>>>>
>>>>> Have you figured out why we access struct pages during hot-unplug for
>>>>> offlined memory? Also, a panic trace would be useful in the patch.
>>>>
>>>> __remove_pages() needs a zone as of now (e.g. to recalculate if the zone
>>>> is contiguous). This zone is taken from the first page of memory to be
>>>> removed. If the struct pages are uninitialized that value is random and
>>>> we might even get an invalid zone.
>>>>
>>>> The zone is also used to locate pgdat.
>>>>
>>>> No stack trace available so far, I'm just reading the code and try to
>>>> understand how this whole memory hotplug/unplug machinery works.
>>>
>>> Yes this is a mess (evolution of the code called otherwise ;) [1].
>>
>> So I guess I should not feel bad if I am having problems understanding
>> all the details? ;)
>>
>>> Functionality has been just added on top of not very well thought
>>> through bases. This is a nice example of it. We are trying to get a zone
>>> to 1) special case zone_device 2) recalculate zone state. The first
>>> shouldn't be really needed because we should simply rely on altmap.
>>> Whether it is used for zone device or not. 2) shouldn't be really needed
>>> if the section is offline and we can check that trivially.
>>>
>>
>> About 2, I am not sure if this is the case and that easy. To me it looks
>> more like remove_pages() fixes up things that should be done in
>> offline_pages(). Especially, if the same memory was onlined/offlined to
>> different zones we might be in trouble (looking at code on a very high
>> level view).
> 
> Well, this might be possible. Hotplug remove path was on my todo list
> for a long time. I didn't get that far TBH. shrink_zone_span begs for
> some attention.
> 

So i guess we agree that the right fix for this is to not touch struct
pages when removing memory, correct?

-- 

Thanks,

David / dhildenb

  reply	other threads:[~2018-07-30 15:03 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-27 16:54 [PATCH v1] mm: inititalize struct pages when adding a section David Hildenbrand
2018-07-27 16:54 ` David Hildenbrand
2018-07-27 17:25 ` Pavel Tatashin
2018-07-27 18:01   ` David Hildenbrand
2018-07-30 11:30 ` Michal Hocko
2018-07-30 11:53   ` David Hildenbrand
2018-07-30 12:05     ` Michal Hocko
2018-07-30 12:11       ` David Hildenbrand
2018-07-30 13:30         ` Pavel Tatashin
2018-07-30 13:51           ` David Hildenbrand
2018-07-30 14:10             ` Michal Hocko
2018-07-30 14:42               ` David Hildenbrand
2018-07-30 14:50                 ` Michal Hocko
2018-07-30 15:03                   ` David Hildenbrand [this message]
2018-07-30 15:45                     ` Pavel Tatashin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=0be90c23-e5a0-2628-c671-9923d8e45b0a@redhat.com \
    --to=david@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=dan.j.williams@intel.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=iamjoonsoo.kim@lge.com \
    --cc=jack@suse.cz \
    --cc=jglisse@redhat.com \
    --cc=jrdr.linux@gmail.com \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=malat@debian.org \
    --cc=mawilcox@microsoft.com \
    --cc=mgorman@suse.de \
    --cc=mhocko@kernel.org \
    --cc=mingo@kernel.org \
    --cc=osalvador@techadventures.net \
    --cc=pasha.tatashin@oracle.com \
    --cc=vbabka@suse.cz \
    --cc=yasu.isimatu@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.