Re: [PATCH part1 v6 4/6] x86/mem-hotplug: Support initialize page tables in bottom-up

[Tejun Heo <tj@kernel.org>]

On Thu, Oct 10, 2013 at 01:17:10PM -0600, Toshi Kani wrote:
> In earlier discussions, Tejun pointed out that huge mappings dismiss the
> benefit of local page tables.
> 
> https://lkml.org/lkml/2013/8/23/245

This is going nowhere.  If we're assuming use of large mappings, none
of this matters.  The pagetable is gonna be small no matter what and
locating it near kernel image doesn't really impact anything whether
hotplug is gonna be per-node or per-device.  Short of the ability to
relocate kernel image itself, parsing or not parsing SRAT early
doesn't lead to anything of consequence.  What are we even arguing
about?  That's what bothers me about this effort.  Nobody seems to
have actually thought it through.

To summarize,

* To do local page table, full ACPI device hierarchy should be parsed.

* Local page table is pointless if you assume huge mappings and the
  plan is to assume huge mappings so that only SRAT is necessary
  before allocating page tables.

* But if you assume huge mappings, it doesn't make material difference
  whether the page table is after the kernel image or near the top of
  non-hotpluggable memory.  It's tiny anyway.

* So, what's the point of pulling SRAT parsing into early boot?  If we
  assume huge mappings, it doesn't make any material difference for
  either per-node or per-device unplug - it's tiny.  If we don't
  assume huge mappings, we're talking about parsing full ACPI device
  tree before building pagetable.  Let's say that's something we can
  accept.  Is the benefit worthwhile?  Doing all that just for debug
  configs?  Is that something people are actually arguing for?  Sure,
  if it works without too much effort, it's great, but do we really
  wanna do all that and update page table allocation so that
  everything is per-device just to support debug configs, for real?

I'm not asking for super concrete plan but right now people working on
this don't seem to have much idea of what the goals are or why they
want certain things and the discussions naturally repeat themselves.
FWIW, I'm getting to a point where I think nacking the whole series is
the right thing to do here.

Thanks.

-- 
tejun

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>