All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oscar Salvador <osalvador@techadventures.net>
To: Michal Hocko <mhocko@kernel.org>
Cc: akpm@linux-foundation.org, pasha.tatashin@oracle.com,
	vbabka@suse.cz, iamjoonsoo.kim@lge.com, aaron.lu@intel.com,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	Oscar Salvador <osalvador@suse.de>
Subject: Re: [PATCH 2/3] mm/page_alloc: Refactor free_area_init_core
Date: Wed, 18 Jul 2018 16:12:26 +0200	[thread overview]
Message-ID: <20180718141226.GA2588@techadventures.net> (raw)
In-Reply-To: <20180718133647.GD7193@dhcp22.suse.cz>

On Wed, Jul 18, 2018 at 03:36:47PM +0200, Michal Hocko wrote:
> On Wed 18-07-18 14:47:21, osalvador@techadventures.net wrote:
> > From: Oscar Salvador <osalvador@suse.de>
> > 
> > When free_area_init_core gets called from the memhotplug code,
> > we only need to perform some of the operations in
> > there.
> 
> Which ones? Or other way around. Which we do not want to do and why?
> 
> > Since memhotplug code is the only place where free_area_init_core
> > gets called while node being still offline, we can better separate
> > the context from where it is called.
> 
> I really do not like this if node is offline than only perform half of
> the function. This will generate more mess in the future. Why don't you
> simply. If we can split out this code into logical units then let's do
> that but no, please do not make random ifs for hotplug code paths.
> Sooner or later somebody will simply don't know what is needed and what
> is not.

Yes, you are right.
I gave it another thought and it was not a really good idea.
Although I think the code from free_area_init_core can be simplified.

I will try to come up with something that makes more sense.

Thanks
-- 
Oscar Salvador
SUSE L3

  reply	other threads:[~2018-07-18 14:12 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-18 12:47 [PATCH 0/3] Re-structure free_area_init_node / free_area_init_core osalvador
2018-07-18 12:47 ` [PATCH 1/3] mm/page_alloc: Move ifdefery out of free_area_init_core osalvador
2018-07-18 13:37   ` Michal Hocko
2018-07-18 14:11   ` Pavel Tatashin
2018-07-18 14:11     ` Pavel Tatashin
2018-07-18 15:15     ` Oscar Salvador
2018-07-19 12:19     ` Oscar Salvador
2018-07-19 13:18       ` Pavel Tatashin
2018-07-18 12:47 ` [PATCH 2/3] mm/page_alloc: Refactor free_area_init_core osalvador
2018-07-18 13:36   ` Michal Hocko
2018-07-18 14:12     ` Oscar Salvador [this message]
2018-07-18 15:11       ` Oscar Salvador
2018-07-18 12:47 ` [PATCH 3/3] mm/page_alloc: Split context in free_area_init_node osalvador
2018-07-18 14:34   ` Pavel Tatashin
2018-07-19  7:35     ` Oscar Salvador

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=20180718141226.GA2588@techadventures.net \
    --to=osalvador@techadventures.net \
    --cc=aaron.lu@intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=iamjoonsoo.kim@lge.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@kernel.org \
    --cc=osalvador@suse.de \
    --cc=pasha.tatashin@oracle.com \
    --cc=vbabka@suse.cz \
    /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.