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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello,

On Thu, Oct 10, 2013 at 08:36:49AM -0600, Toshi Kani wrote:
> >  "3. Improve memory hotplug to support local device pagetable."
> > 
> > How can the above possibly be considered as a plan for finer
> > granularity?  Forget about the "how" part.  The stated goal doesn't
> > even mention finer granularity.  
> 
> The word "device" above refers memory device level granularity.  

That's a lot of reading inbetween the words.

> > Are firmware writers gonna be
> > required to split SRAT entries into multiple sub-nodes to support it?
> 
> Yes, and that's part of the ACPI spec.  That's not something the OS
> requests to do.  If a memory range has different attribute, firmware has
> to put it in a separate entry.

I was referring to having to segment a contiguous hotplug memory area
further to support finer granularity.  This is represented by separate
mem devices rather than segmented SRAT entries, right?  Hmmm... so we
should parse device nodes before setting up page tables?

> SRAT and _EJ0 method are the only interfaces that define ejectability in
> the standard spec.  Are you suggesting us to change the e820 spec or not
> to comply with the spec?  I do not think such approaches work.    

It's slower but standards get revised and updated over time.  Have no
idea whether there'd be a sane way to do that for e820 tho.

> I think memory hotplug was originally implemented on ia64 with the node
> granularity.  I share your concerns, but that's been done a long time
> ago.  It's too late to complain the past.  This SRAT work is not
> introducing such restriction.

We're going round and round.  You're saying that using SRAT isn't
worse than what came before while failing to illustrate how committing
to invasive changes would eventually lead to something better.  "it
isn't worse" isn't much of an argument.

Thanks.

-- 
tejun

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




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]