From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-f71.google.com (mail-ed1-f71.google.com [209.85.208.71]) by kanga.kvack.org (Postfix) with ESMTP id B59726B4566 for ; Mon, 26 Nov 2018 22:12:03 -0500 (EST) Received: by mail-ed1-f71.google.com with SMTP id q8so4872730edd.8 for ; Mon, 26 Nov 2018 19:12:03 -0800 (PST) Received: from mail-sor-f65.google.com (mail-sor-f65.google.com. [209.85.220.65]) by mx.google.com with SMTPS id f2sor1697879ede.19.2018.11.26.19.12.02 for (Google Transport Security); Mon, 26 Nov 2018 19:12:02 -0800 (PST) Date: Tue, 27 Nov 2018 03:12:00 +0000 From: Wei Yang Subject: Re: [PATCH] mm, hotplug: protect nr_zones with pgdat_resize_lock() Message-ID: <20181127031200.46mu6moxcxat57wz@master> Reply-To: Wei Yang References: <20181120014822.27968-1-richard.weiyang@gmail.com> <20181120073141.GY22247@dhcp22.suse.cz> <3ba8d8c524d86af52e4c1fddc2d45734@suse.de> <20181121025231.ggk7zgq53nmqsqds@master> <20181121071549.GG12932@dhcp22.suse.cz> <20181126081608.GE12455@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20181126081608.GE12455@dhcp22.suse.cz> Sender: owner-linux-mm@kvack.org List-ID: To: Michal Hocko Cc: Wei Yang , Oscar Salvador , Andrew Morton , Linux-MM On Mon, Nov 26, 2018 at 09:16:08AM +0100, Michal Hocko wrote: >On Mon 26-11-18 10:28:40, Wei Yang wrote: >[...] >> But I get some difficulty to understand this TODO. You want to get rid of >> these lock? While these locks seem necessary to protect those data of >> pgdat/zone. Would you mind sharing more on this statement? > >Why do we need this lock to be irqsave? Is there any caller that uses >the lock from the IRQ context? Went through the code, we have totally 9 place acquire pgdat_resize_lock: lib/show_mem.c: 1 show_mem() mm/memory_hotplug.c: 4 online/offline_pages/__remove_zone() mm/page_alloc.c: 2 defer_init mm/sparse.c: 2 not necessary Two places I am not sure: * show_mem() would be called from __alloc_pages_slowpath() * __remove_zone() is related to acpi_scan() on x86, may related to other method on different arch I am not 100% for sure, while they looks like to be called in IRQ context. My ugly idea is: * drop pgdat_resize_lock in show_mem(), we don't change the value here. or replace this with a read/write lock? * can we adjust pgdat's range in offline_pages()? This would be consistent since we adjust them in online_pages(). >-- >Michal Hocko >SUSE Labs -- Wei Yang Help you, Help me