x86, memblock: Allocate memory near kernel image before SRAT parsed

From: Tang Chen <[email protected]>

The Linux kernel cannot migrate pages used by the kernel. As a result, kernel pages cannot be hot-removed. So we cannot allocate hotpluggable memory for the kernel.

ACPI SRAT (System Resource Affinity Table) contains the memory hotplug info. But before SRAT is parsed, memblock has already started to allocate memory for the kernel. So we need to prevent memblock from doing this.

In a memory hotplug system, any numa node the kernel resides in should be unhotpluggable. And for a modern server, each node could have at least 16GB memory. So memory around the kernel image is highly likely unhotpluggable.

So the basic idea is: Allocate memory from the end of the kernel image and to the higher memory. Since memory allocation before SRAT is parsed won't be too much, it could highly likely be in the same node with kernel image.

The current memblock can only allocate memory top-down. So this patch introduces a new bottom-up allocation mode to allocate memory bottom-up. And later when we use this allocation direction to allocate memory, we will limit the start address above the kernel.

Signed-off-by Tang Chen <[email protected]>

Signed-off-by Zhang Yanfei <[email protected]>

From: Tang Chen <[email protected]>

The Linux kernel cannot migrate pages used by the kernel. As a result, kernel pages cannot be hot-removed. So we cannot allocate hotpluggable memory for the kernel.

In a memory hotplug system, any numa node the kernel resides in should be unhotpluggable. And for a modern server, each node could have at least 16GB memory. So memory around the kernel image is highly likely unhotpluggable.

ACPI SRAT (System Resource Affinity Table) contains the memory hotplug info. But before SRAT is parsed, memblock has already started to allocate memory for the kernel. So we need to prevent memblock from doing this.

So direct memory mapping page tables setup is the case. init_mem_mapping() is called before SRAT is parsed. To prevent page tables being allocated within hotpluggable memory, we will use bottom-up direction to allocate page tables from the end of kernel image to the higher memory.

Acked-by Tejun Heo <[email protected]>

Signed-off-by Tang Chen <[email protected]>

Signed-off-by Zhang Yanfei <[email protected]>

From: Tang Chen <[email protected]>

The Linux kernel cannot migrate pages used by the kernel. As a result, kernel pages cannot be hot-removed. So we cannot allocate hotpluggable memory for the kernel.

In a memory hotplug system, any numa node the kernel resides in should be unhotpluggable. And for a modern server, each node could have at least 16GB memory. So memory around the kernel image is highly likely unhotpluggable.

ACPI SRAT (System Resource Affinity Table) contains the memory hotplug info. But before SRAT is parsed, memblock has already started to allocate memory for the kernel. So we need to prevent memblock from doing this.

So direct memory mapping page tables setup is the case. init_mem_mapping() is called before SRAT is parsed. To prevent page tables being allocated within hotpluggable memory, we will use bottom-up direction to allocate page tables from the end of kernel image to the higher memory.

Acked-by Tejun Heo <[email protected]>

Signed-off-by Tang Chen <[email protected]>

Signed-off-by Zhang Yanfei <[email protected]>

Quoted 21 lines · Zhang Yanfei

From: Tang Chen <[email protected]>

The Linux kernel cannot migrate pages used by the kernel. As a result, kernel pages cannot be hot-removed. So we cannot allocate hotpluggable memory for the kernel.

In a memory hotplug system, any numa node the kernel resides in should be unhotpluggable. And for a modern server, each node could have at least 16GB memory. So memory around the kernel image is highly likely unhotpluggable.

ACPI SRAT (System Resource Affinity Table) contains the memory hotplug info. But before SRAT is parsed, memblock has already started to allocate memory for the kernel. So we need to prevent memblock from doing this.

So direct memory mapping page tables setup is the case. init_mem_mapping() is called before SRAT is parsed. To prevent page tables being allocated within hotpluggable memory, we will use bottom-up direction to allocate page tables from the end of kernel image to the higher memory.

Quoted 3 lines

Acked-by Tejun Heo <[email protected]>

Signed-off-by Tang Chen <[email protected]>

Signed-off-by Zhang Yanfei <[email protected]>

I'm still seriously concerned about this. This unconditionally introduces new behavior which may very well break some classes of

systems -- the whole point of creating the page tables top down is because the kernel tends to be allocated in lower memory, which is also the memory that some devices need for DMA.

arch/x86/mm/init.c +5 -0

+#ifdef CONFIG_X86
+		kernel_end = __pa_symbol(_end);
+#else
+		kernel_end = __pa(RELOC_HIDE((unsigned long)(_end), 0));
+#endif

We really should make __pa_symbol() available everywhere by putting something like the above in a global define (under #ifndef __pa_symbol).

Is RELOC_HIDE() even correct here?

Quoted 16 lines · Zhang Yanfei

From: Tang Chen <[email protected]>

The Linux kernel cannot migrate pages used by the kernel. As a result, kernel pages cannot be hot-removed. So we cannot allocate hotpluggable memory for the kernel.

In a memory hotplug system, any numa node the kernel resides in should be unhotpluggable. And for a modern server, each node could have at least 16GB memory. So memory around the kernel image is highly likely unhotpluggable.

ACPI SRAT (System Resource Affinity Table) contains the memory hotplug info. But before SRAT is parsed, memblock has already started to allocate memory for the kernel. So we need to prevent memblock from doing this.

Quoted 8 lines

So direct memory mapping page tables setup is the case. init_mem_mapping() is called before SRAT is parsed. To prevent page tables being allocated within hotpluggable memory, we will use bottom-up direction to allocate page tables from the end of kernel image to the higher memory.

Acked-by Tejun Heo <[email protected]>

Signed-off-by Tang Chen <[email protected]>

Signed-off-by Zhang Yanfei <[email protected]>

I'm still seriously concerned about this. This unconditionally introduces new behavior which may very well break some classes of systems -- the whole point of creating the page tables top down is because the kernel tends to be allocated in lower memory, which is also the memory that some devices need for DMA.

so if we allocate memory close to the kernel image,
it's likely that we don't contaminate hotpluggable node. We're talking about few megs at most right after the kernel image. I can't see how that would make any noticeable difference.

Quoted 2 lines

I'm still seriously concerned about this. This unconditionally introduces new behavior which may very well break some classes of

Quoted 3 lines

systems -- the whole point of creating the page tables top down is because the kernel tends to be allocated in lower memory, which is also the memory that some devices need for DMA.

Quoted 4 lines

so if we allocate memory close to the kernel image,
it's likely that we don't contaminate hotpluggable node. We're talking about few megs at most right after the kernel image. I can't see how that would make any noticeable difference.

You meant that the memory size is about few megs. But here, page tables seems to be large enough in big memory machines, so that page tables will

consume the precious lower memory. So I think we may really reorder the page table setup after we get the hotplug info in some way. Just like we have done in patch 5, we reorder reserve_crashkernel() to be called after initmem_init().

So do you still have any objection to the pagetable setup reorder?

Hello,

Quoted 2 lines · Zhang Yanfei

Quoted 2 lines

I'm still seriously concerned about this. This unconditionally introduces new behavior which may very well break some classes of

This is an optional behavior which is triggered by a very specific kernel boot param, which I suspect is gonna need to stick around to support memory hotplug in the current setup unless we add another layer of address translation to support memory hotplug.

Quoted 4 lines

Quoted 4 lines

systems -- the whole point of creating the page tables top down is because the kernel tends to be allocated in lower memory, which is also the memory that some devices need for DMA.

Would that really matter for the target use cases here? These are likely fairly huge highend machines. ISA DMA limit is below the kernel image and 32bit limit is pretty big in comparison and at this point even that limit is likely to be irrelevant at least for the target machines, which are gonna be almost inherently extremely niche.

Quoted 5 lines

Quoted 4 lines

so if we allocate memory close to the kernel image,
it's likely that we don't contaminate hotpluggable node. We're talking about few megs at most right after the kernel image. I can't see how that would make any noticeable difference.

Quoted 2 lines

You meant that the memory size is about few megs. But here, page tables seems to be large enough in big memory machines, so that page tables will

Hmmm? Even with 4k mappings and, say, 16Gigs of memory, it's still somewhere above 32MiB, right? And, these physical mappings don't usually use 4k mappings to begin with. Unless we're worrying about ISA DMA limit, I don't think it'd be problematic.

Quoted 7 lines

consume the precious lower memory. So I think we may really reorder the page table setup after we get the hotplug info in some way. Just like we have done in patch 5, we reorder reserve_crashkernel() to be called after initmem_init().

So do you still have any objection to the pagetable setup reorder?

I still feel quite uneasy about pulling SRAT parsing and ACPI initrd overriding into early boot.

Quoted 7 lines

Quoted 2 lines

You meant that the memory size is about few megs. But here, page tables seems to be large enough in big memory machines, so that page tables will

Hmmm? Even with 4k mappings and, say, 16Gigs of memory, it's still somewhere above 32MiB, right? And, these physical mappings don't usually use 4k mappings to begin with. Unless we're worrying about ISA DMA limit, I don't think it'd be problematic.

I think Peter meant very huge memory machines, say 2T memory? In the worst case, this may need 2G memory for page tables, seems huge....

And I am not familiar with the ISA DMA limit, does this mean the memory below 4G? Just as we have the ZONE_DMA32 in x86_64. (16MB limit seems not the case here)

1. introduce bottom up allocation to allocate memory near the kernel before we parse SRAT.
2. Since peter have the serious concern about the pagetable setup in bottom-up and Ingo also said we'd better not to touch the current top-down pagetable setup. Could we just put acpi_initrd_override and numa_init related functions before init_mem_mapping()? After numa info is parsed (including SRAT), we reset the allocation direction back to top-down, so we needn't change the page table setup process. And before numa info parsed, we use the bottom-up allocation to make sure all memory allocated by memblock is near the kernel image.

How do you think?

Realistically tho, why would people be using 4k mappings on 2T machines?

Quoted 2 lines · Tejun Heo

Realistically tho, why would people be using 4k mappings on 2T machines?

CONFIG_DEBUG_PAGEALLOC and CONFIG_KMEMCHECK both disable using >4k pages. I actually ran in to this on a 1TB machine a few weeks ago:

	https://lkml.org/lkml/2013/8/9/546

So it's not a common case for stuff that customers have, but it sure as *HECK* is needed for debugging.

Hello,

Quoted 10 lines · Zhang Yanfei

Quoted 7 lines

Quoted 2 lines

You meant that the memory size is about few megs. But here, page tables seems to be large enough in big memory machines, so that page tables will

Hmmm? Even with 4k mappings and, say, 16Gigs of memory, it's still somewhere above 32MiB, right? And, these physical mappings don't usually use 4k mappings to begin with. Unless we're worrying about ISA DMA limit, I don't think it'd be problematic.

I think Peter meant very huge memory machines, say 2T memory? In the worst case, this may need 2G memory for page tables, seems huge....

Realistically tho, why would people be using 4k mappings on 2T machines? For the sake of argument, let's say 4k mappings are required for some weird reason, even then, doing SRAT parsing early doesn't necessarily solve the problem in itself. It'd still need heuristics to avoid occupying too much of 32bit memory because it isn't difficult to imagine specific NUMA settings which would drive page table allocation into low address.

No matter what we do, there's no way around the fact that this whole effort is mostly an incomplete solution in its nature and that's why I think we better keep things isolated and simple. It isn't a good idea to make structural changes to accomodate something which isn't and doesn't have much chance of becoming a full solution. In addition, the problem itself is niche to begin with.

Let's not assume that memory hotplug is always a niche feature for huge & special systems. It may be a niche to begin with, but it could be supported on VMs, which allows anyone to use. Vasilis has been working on KVM to support memory hotplug.

Hello, Toshi.

Quoted 4 lines · Toshi Kani

Let's not assume that memory hotplug is always a niche feature for huge & special systems. It may be a niche to begin with, but it could be supported on VMs, which allows anyone to use. Vasilis has been working on KVM to support memory hotplug.

I'm not saying hotplug will always be niche. I'm saying the approach we're currently taking is. It seems fairly inflexible to hang the whole thing on NUMA nodes. What does the planned kvm support do? Splitting SRAT nodes so that it can do both actual NUMA node distribution and hotplug granuliarity? IIRC I asked a couple times what the long term plan was for this feature and there doesn't seem to be any road map for this thing to become a full solution. Unless I misunderstood, this is more of "let's put out the fire as there already are (or gonna be) machines which can do it" kinda thing, which is fine too. My point is that it doesn't make a lot of sense to change boot sequence invasively to accomodate that.

Quoted 8 lines · Tejun Heo

Hello, Toshi.

Quoted 4 lines · Toshi Kani

Let's not assume that memory hotplug is always a niche feature for huge & special systems. It may be a niche to begin with, but it could be supported on VMs, which allows anyone to use. Vasilis has been working on KVM to support memory hotplug.

Quoted 12 lines

I'm not saying hotplug will always be niche. I'm saying the approach we're currently taking is. It seems fairly inflexible to hang the whole thing on NUMA nodes. What does the planned kvm support do? Splitting SRAT nodes so that it can do both actual NUMA node distribution and hotplug granuliarity? IIRC I asked a couple times what the long term plan was for this feature and there doesn't seem to be any road map for this thing to become a full solution. Unless I misunderstood, this is more of "let's put out the fire as there already are (or gonna be) machines which can do it" kinda thing, which is fine too. My point is that it doesn't make a lot of sense to change boot sequence invasively to accomodate that.

I would also argue that in the VM scenario -- and arguable even in the hardware scenario -- the right thing is to not expose the flexible memory in the e820/EFI tables, and instead have it hotadded (possibly *immediately* so) on boot. This avoids both the boot time funnies as well as the scaling issues with metadata.

Quoted 7 lines

I would also argue that in the VM scenario -- and arguable even in the hardware scenario -- the right thing is to not expose the flexible memory in the e820/EFI tables, and instead have it hotadded (possibly *immediately* so) on boot. This avoids both the boot time funnies as well as the scaling issues with metadata.

So in this kind of scenario, hotpluggable memory will not be detected at boot time, and admin should not use this movable_node boot option and the kernel will act as before, using top-down allocation always.

Quoted 8 lines · Zhang Yanfei

Quoted 7 lines

I would also argue that in the VM scenario -- and arguable even in the hardware scenario -- the right thing is to not expose the flexible memory in the e820/EFI tables, and instead have it hotadded (possibly *immediately* so) on boot. This avoids both the boot time funnies as well as the scaling issues with metadata.

Quoted 4 lines

So in this kind of scenario, hotpluggable memory will not be detected at boot time, and admin should not use this movable_node boot option and the kernel will act as before, using top-down allocation always.

Yes. The idea is that the kernel will boot up without the hotplug memory, but if desired, will immediately see a hotplug-add event for the movable memory.

Hello Peter,

Quoted 9 lines · H. Peter Anvin

Quoted 8 lines · Zhang Yanfei

Quoted 7 lines

I would also argue that in the VM scenario -- and arguable even in the hardware scenario -- the right thing is to not expose the flexible memory in the e820/EFI tables, and instead have it hotadded (possibly *immediately* so) on boot. This avoids both the boot time funnies as well as the scaling issues with metadata.

Quoted 8 lines

Quoted 4 lines

So in this kind of scenario, hotpluggable memory will not be detected at boot time, and admin should not use this movable_node boot option and the kernel will act as before, using top-down allocation always.

Yes. The idea is that the kernel will boot up without the hotplug memory, but if desired, will immediately see a hotplug-add event for the movable memory.

Yeah, this is good.

But in the scenario that boot with hotplug memory, we need the movable_node option. So as tejun has explained a lot about this patchset, do you still have objection to it or could I ask andrew to merge it into -mm tree for more tests?

Quoted 8 lines · Tejun Heo

Hello, Toshi.

Quoted 4 lines · Toshi Kani

Let's not assume that memory hotplug is always a niche feature for huge & special systems. It may be a niche to begin with, but it could be supported on VMs, which allows anyone to use. Vasilis has been working on KVM to support memory hotplug.

Quoted 12 lines

I'm not saying hotplug will always be niche. I'm saying the approach we're currently taking is. It seems fairly inflexible to hang the whole thing on NUMA nodes. What does the planned kvm support do? Splitting SRAT nodes so that it can do both actual NUMA node distribution and hotplug granuliarity? IIRC I asked a couple times what the long term plan was for this feature and there doesn't seem to be any road map for this thing to become a full solution. Unless I misunderstood, this is more of "let's put out the fire as there already are (or gonna be) machines which can do it" kinda thing, which is fine too. My point is that it doesn't make a lot of sense to change boot sequence invasively to accomodate that.

I would also argue that in the VM scenario -- and arguable even in the hardware scenario -- the right thing is to not expose the flexible memory in the e820/EFI tables, and instead have it hotadded (possibly *immediately* so) on boot. This avoids both the boot time funnies as well as the scaling issues with metadata.

The whole reason for VMs wanting this is because ballooning doesn't scale with regards to metadata.

Quoted 4 lines · Toshi Kani

Let's not assume that memory hotplug is always a niche feature for huge & special systems. It may be a niche to begin with, but it could be supported on VMs, which allows anyone to use. Vasilis has been working on KVM to support memory hotplug.

I'm not saying hotplug will always be niche.

I'm saying the approach
we're currently taking is. It seems fairly inflexible to hang the whole thing on NUMA nodes. What does the planned kvm support do? Splitting SRAT nodes so that it can do both actual NUMA node distribution and hotplug granuliarity?

IIRC I asked a couple times
what the long term plan was for this feature and there doesn't seem to be any road map for this thing to become a full solution. Unless I misunderstood, this is more of "let's put out the fire as there already are (or gonna be) machines which can do it" kinda thing, which is fine too. My point is that it doesn't make a lot of sense to change boot sequence invasively to accomodate that.

Well, there was a plan before, which considered to enhance it to a memory device granularity at step 3. But we had a major replan at step 1 per your suggestion.

https://lkml.org/lkml/2013/6/19/73

Hello, Toshi.

Quoted 5 lines · Toshi Kani

Well, there was a plan before, which considered to enhance it to a memory device granularity at step 3. But we had a major replan at step 1 per your suggestion.

https://lkml.org/lkml/2013/6/19/73

Where?

"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.

Are firmware writers gonna be
required to split SRAT entries into multiple sub-nodes to support it?

Is segregating zones further for this even a good idea? Adding more NUMA nodes has its own overhead and the mm code isn't written expecting it to be repurposed for segmenting the same NUMA node for hotplug underneath it.

Maybe zoning is a viable approach. Maybe it is not. I don't know, but you guys don't seem to be too interested in actual long term planning while pushing for something invasive which may or may not be viable in the longer term, which can often lead to silly situations. It isn't even clear whether SRAT is the right interface for this. If it's gonna require firwmare writer's cooperation anyway, why not provide the information as extended part of e820? It doesn't seem to have much to do with NUMA or zones. The only information the kernel needs to know is whether certain memory areas should only be used for page cache.

At this point, at least to me, it doesn't seem reasonably clear how this is gonna develop and the whole thing feels like a kludge, which can be fine too, but seriously if you guys wanna push for an invasive approach, it should really be backed by longer term plan, vision, justification and the ability to make the necessary changes in the various involved layers. Maybe I'm being too pessimistic but I feel that there are a lot missing in most of those areas, which makes it quite risky to commit to invasive changes.

If the zone based kludgy appraoch is something meaningfully useful, I'd suggest to sticking to it at least for now. Some of it would be useful anyway and if it doesn't fan out the added maintenance overhead is fairly low.

Quoted 5 lines

"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.

Quoted 2 lines

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.

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.

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.

Quoted 6 lines

Quoted 2 lines

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?

Quoted 3 lines

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.

Quoted 4 lines

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.

Quoted 4 lines

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.

We did avoid moving up the ACPI table init function per your suggestion. I guess I do not understand why you still concerned about using SRAT...

Quoted 7 lines · Toshi Kani

Quoted 4 lines

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.

We did avoid moving up the ACPI table init function per your suggestion. I guess I do not understand why you still concerned about using SRAT...

As you wrote above, SRAT is not enough to support device granularity. We need to parse the device hierarchy too before setting up page tables and one of the previous arguments was "it's only SRAT". It doesn't instill confidence when there doesn't seem to be much long term planning going on especially as the general quality of the patches isn't particularly high. I find it difficult to believe that this effort as it currently stands is likely to reach full solution and as such it feels much safer to opt for a simpler, less dangerous approach for immedate use, for which either approach doesn't make much of difference.

Can you elaborate why we need to parse the device hierarchy before setting up page tables?

Quoted 2 lines · Toshi Kani

Can you elaborate why we need to parse the device hierarchy before setting up page tables?

How else can one put the page tables on the "local device"? Am I missing something?

Quoted 6 lines · Tejun Heo

Quoted 2 lines · Toshi Kani

Can you elaborate why we need to parse the device hierarchy before setting up page tables?

How else can one put the page tables on the "local device"? Am I missing something?

The local page table item is gone under the current plan as you suggested...

Quoted 5 lines · Toshi Kani

Quoted 4 lines · Tejun Heo

Quoted 2 lines · Toshi Kani

Can you elaborate why we need to parse the device hierarchy before setting up page tables?

Quoted 6 lines

Quoted 2 lines

How else can one put the page tables on the "local device"? Am I missing something?

The local page table item is gone under the current plan as you suggested...

That would be a significant performance regression.

In earlier discussions, Tejun pointed out that huge mappings dismiss the benefit of local page tables.

https://lkml.org/lkml/2013/8/23/245

Quoted 4 lines · Toshi Kani

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.

Hello,

Quoted 10 lines · Zhang Yanfei

Quoted 7 lines

Quoted 2 lines

You meant that the memory size is about few megs. But here, page tables seems to be large enough in big memory machines, so that page tables will

Hmmm? Even with 4k mappings and, say, 16Gigs of memory, it's still somewhere above 32MiB, right? And, these physical mappings don't usually use 4k mappings to begin with. Unless we're worrying about ISA DMA limit, I don't think it'd be problematic.

I think Peter meant very huge memory machines, say 2T memory? In the worst case, this may need 2G memory for page tables, seems huge....

Realistically tho, why would people be using 4k mappings on 2T machines? For the sake of argument, let's say 4k mappings are required for some weird reason, even then, doing SRAT parsing early doesn't necessarily solve the problem in itself. It'd still need heuristics to avoid occupying too much of 32bit memory because it isn't difficult to imagine specific NUMA settings which would drive page table allocation into low address.

No matter what we do, there's no way around the fact that this whole effort is mostly an incomplete solution in its nature and that's why I think we better keep things isolated and simple. It isn't a good idea to make structural changes to accomodate something which isn't and doesn't have much chance of becoming a full solution. In addition, the problem itself is niche to begin with.

Quoted 3 lines

And I am not familiar with the ISA DMA limit, does this mean the memory below 4G? Just as we have the ZONE_DMA32 in x86_64. (16MB limit seems not the case here)

Yeah, I was referring to the 16MB limit, which apparently ceased to exist.

Quoted 3 lines

Yeah, I was referring to the 16MB limit, which apparently ceased to exist.

Hmmmm...If we are talking 16MB limit hear, I don't think it a problem, either. Currently, default loading & running address of kernel is 16MB, so the kernel itself is above 16MB, memory allocated in bottom-up mode is obviously above the 16MB. Just seeing from a RHEL6.3 server:

01000000-01507ff4 : Kernel code
01507ff5-01c07b2f : Kernel data
01d4e000-02012023 : Kernel bss

IOW, even if kernel is loaded and running at 1MB, it self will occupy about 16MB from the above.

Quoted 13 lines · Zhang Yanfei

Quoted 3 lines

Yeah, I was referring to the 16MB limit, which apparently ceased to exist.

Hmmmm...If we are talking 16MB limit hear, I don't think it a problem, either. Currently, default loading & running address of kernel is 16MB, so the kernel itself is above 16MB, memory allocated in bottom-up mode is obviously above the 16MB. Just seeing from a RHEL6.3 server:

01000000-01507ff4 : Kernel code
01507ff5-01c07b2f : Kernel data
01d4e000-02012023 : Kernel bss

Quoted 3 lines

IOW, even if kernel is loaded and running at 1MB, it self will occupy about 16MB from the above.

For various DMA devices you can find almost every possible power of 2 being a limitation. The most common limits are 24, 32, and 40 bits, but you also see odd ones like 30 bits in the field. Really.

Quoted 6 lines

consume the precious lower memory. So I think we may really reorder the page table setup after we get the hotplug info in some way. Just like we have done in patch 5, we reorder reserve_crashkernel() to be called after initmem_init().

So do you still have any objection to the pagetable setup reorder?

I still feel quite uneasy about pulling SRAT parsing and ACPI initrd overriding into early boot.

Quoted 2 lines

I still feel quite uneasy about pulling SRAT parsing and ACPI initrd overriding into early boot.

for your reconsidering to parse srat early, I refresh that old patchset at

https://git.kernel.org/cgit/linux/kernel/git/yinghai/linux-yinghai.git/log/?h=for-x86-mm-3.13

actually looks one-third or haf patches already have your ack.

Hello, Yinghai.

Quoted 8 lines · Yinghai Lu

Quoted 2 lines

I still feel quite uneasy about pulling SRAT parsing and ACPI initrd overriding into early boot.

for your reconsidering to parse srat early, I refresh that old patchset at

https://git.kernel.org/cgit/linux/kernel/git/yinghai/linux-yinghai.git/log/?h=for-x86-mm-3.13

Quoted 1 line

actually looks one-third or haf patches already have your ack.

Yes, but those acks assume that the overall approach is a good idea. The biggest issue that I have with the approach is that it is invasive and modifies basic structure for an inherently kludgy solution for a quite niche problem. The benefit / cost ratio still seems quite off to me - we're making a lot of general changes to serve something very specialized, which might not even stay relevant for long time.

Quoted 11 lines · Tejun Heo

Hello, Yinghai.

Quoted 8 lines · Yinghai Lu

Quoted 2 lines

I still feel quite uneasy about pulling SRAT parsing and ACPI initrd overriding into early boot.

for your reconsidering to parse srat early, I refresh that old patchset at

https://git.kernel.org/cgit/linux/kernel/git/yinghai/linux-yinghai.git/log/?h=for-x86-mm-3.13

Quoted 9 lines

Quoted 1 line

actually looks one-third or haf patches already have your ack.

Yes, but those acks assume that the overall approach is a good idea. The biggest issue that I have with the approach is that it is invasive and modifies basic structure for an inherently kludgy solution for a quite niche problem. The benefit / cost ratio still seems quite off to me - we're making a lot of general changes to serve something very specialized, which might not even stay relevant for long time.

I really hate adding another the code path.

Now with v7 from Yanfei, will have movable_node boot command parameter and if that is specified kernel would allocate ram early in different way.

Parse srat early patchset add about 217 lines, (from x86, ACPI, NUMA,
ia64: split SLIT handling out)

 arch/ia64/kernel/setup.c                |   4 +-
 arch/x86/include/asm/acpi.h             |   3 +-
 arch/x86/include/asm/page_types.h       |   2 +-
 arch/x86/include/asm/pgtable.h          |   2 +-
 arch/x86/include/asm/setup.h            |   9 ++
 arch/x86/kernel/head64.c                |   2 +
 arch/x86/kernel/head_32.S               |   4 +
 arch/x86/kernel/microcode_intel_early.c |   8 +-
 arch/x86/kernel/setup.c                 |  86 ++++++-----
 arch/x86/mm/init.c                      | 101 ++++++++-----
 arch/x86/mm/numa.c                      | 244 +++++++++++++++++++++++++-------
 arch/x86/mm/numa_emulation.c            |   2 +-
 arch/x86/mm/numa_internal.h             |   2 +
 arch/x86/mm/srat.c                      |  11 +-
 drivers/acpi/numa.c                     |  13 +-
 drivers/acpi/osl.c                      | 131 ++++++++++++-----
 include/linux/acpi.h                    |  20 +--
 include/linux/mm.h                      |   3 -
 mm/page_alloc.c                         |  52 +------
 19 files changed, 458 insertions(+), 241 deletions(-)

if I drop last two, aka does not allocate page table on local code. will only keep page table on first node, will only need to have add 137 lines.

 arch/ia64/kernel/setup.c                |   4 +-
 arch/x86/include/asm/acpi.h             |   3 +-
 arch/x86/include/asm/page_types.h       |   2 +-
 arch/x86/include/asm/setup.h            |   9 ++
 arch/x86/kernel/head64.c                |   2 +
 arch/x86/kernel/head_32.S               |   4 +
 arch/x86/kernel/microcode_intel_early.c |   8 +-
 arch/x86/kernel/setup.c                 |  85 +++++++++------
 arch/x86/mm/init.c                      |  10 +-
 arch/x86/mm/numa.c                      | 188 +++++++++++++++++++++++---------
 arch/x86/mm/numa_emulation.c            |   2 +-
 arch/x86/mm/numa_internal.h             |   2 +
 arch/x86/mm/srat.c                      |  11 +-
 drivers/acpi/numa.c                     |  13 ++-
 drivers/acpi/osl.c                      | 131 +++++++++++++++-------
 include/linux/acpi.h                    |  20 ++--
 include/linux/mm.h                      |   3 -
 mm/page_alloc.c                         |  52 +--------
 18 files changed, 343 insertions(+), 206 deletions(-)

and Yanfei's add about 265 lines

Documentation/kernel-
parameters.txt | 3 +

 arch/x86/kernel/setup.c             |    9 ++-
 arch/x86/mm/init.c                  |  122 ++++++++++++++++++++++++++++------
 arch/x86/mm/numa.c                  |   11 +++
 include/linux/memblock.h            |   24 +++++++
 include/linux/mm.h                  |    4 +
 mm/Kconfig                          |   17 +++--
 mm/memblock.c                       |  126 +++++++++++++++++++++++++++++++----
 mm/memory_hotplug.c                 |   31 +++++++++
 9 files changed, 306 insertions(+), 41 deletions(-)

For long term to keep the code more maintainable, We really should go though parse srat table early.

Thanks

Yinghai

Hello yinghai,

I know your opinion but take code modification as an example seems like it doesn't stand. More code doesn't mean more complexity......

Quoted 2 lines

For long term to keep the code more maintainable, We really should go though parse srat table early.

Quoted 4 lines · Zhang Yanfei

Hello yinghai,

I know your opinion but take code modification as an example seems like it doesn't stand. More code doesn't mean more complexity......

I think you forgot to reply to this point:

Quoted 2 lines

Quoted 2 lines

For long term to keep the code more maintainable, We really should go though parse srat table early.

From: Tang Chen <[email protected]>

Memory reserved for crashkernel could be large. So we should not allocate this memory bottom up from the end of kernel image.

When SRAT is parsed, we will be able to know whihc memory is hotpluggable, and we can avoid allocating this memory for the kernel. So reorder reserve_crashkernel() after SRAT is parsed.

Acked-by Tejun Heo <[email protected]>

Signed-off-by Tang Chen <[email protected]>

Signed-off-by Zhang Yanfei <[email protected]>

From: Tang Chen <[email protected]>

The hot-Pluggable field in SRAT specifies which memory is hotpluggable. As we mentioned before, if hotpluggable memory is used by the kernel, it cannot be hot-removed. So memory hotplug users may want to set all hotpluggable memory in ZONE_MOVABLE so that the kernel won't use it.

Memory hotplug users may also set a node as movable node, which has ZONE_MOVABLE only, so that the whole node can be hot-removed.

But the kernel cannot use memory in ZONE_MOVABLE. By doing this, the kernel cannot use memory in movable nodes. This will cause NUMA performance down. And other users may be unhappy.

So we need a way to allow users to enable and disable this functionality. In this patch, we introduce movable_node boot option to allow users to choose to not to consume hotpluggable memory at early boot time and later we can set it as ZONE_MOVABLE.

To achieve this, the movable_node boot option will control the memblock allocation direction. That said, after memblock is ready, before SRAT is parsed, we should allocate memory near the kernel image as we explained in the previous patches. So if movable_node boot option is set, the kernel does the following:

1. After memblock is ready, make memblock allocate memory bottom up.
2. After SRAT is parsed, make memblock behave as default, allocate memory top down.

Users can specify "movable_node" in kernel commandline to enable this functionality. For those who don't use memory hotplug or who don't want to lose their NUMA performance, just don't specify anything. The kernel will work as before.

Suggested-by Kamezawa Hiroyuki <[email protected]>

Suggested-by Ingo Molnar <[email protected]>

Acked-by Tejun Heo <[email protected]>

Signed-off-by Tang Chen <[email protected]>

Signed-off-by Zhang Yanfei <[email protected]>

---
 Documentation/kernel-parameters.txt |    3 +++
 arch/x86/mm/numa.c                  |   11 +++++++++++
 mm/Kconfig                          |   17 ++++++++++++-----
 mm/memory_hotplug.c                 |   31 +++++++++++++++++++++++++++++++
 4 files changed, 57 insertions(+), 5 deletions(-)

Documentation/kernel-parameters.txt +0 -0

index 539a236..13201d4 100644

Documentation/kernel-parameters.txt +1 -0

+
 	MTD_Partition=	[MTD]
 			Format: <name>,<region-number>,<size>,<offset>
 

arch/x86/mm/numa.c +11 -0

index 8bf93ba..24aec58 100644
@@ -567,6 +567,17 @@ static int __init numa_init(int (*init_func)(void))
 	ret = init_func();
 	if (ret < 0)
 		return ret;
+
+	/*
+	 * We reset memblock back to the top-down direction
+	 * here because if we configured ACPI_NUMA, we have
+	 * parsed SRAT in init_func(). It is ok to have the
+	 * reset here even if we did't configure ACPI_NUMA
+	 * or acpi numa init fails and fallbacks to dummy
+	 * numa init.
+	 */
+	memblock_set_bottom_up(false);
+
 	ret = numa_cleanup_meminfo(&numa_meminfo);
 	if (ret < 0)
 		return ret;

mm/Kconfig +0 -0

index 026771a..0db1cc6 100644
@@ -153,11 +153,18 @@ config MOVABLE_NODE
 	help
 	  Allow a node to have only movable memory.  Pages used by the kernel,
 	  such as direct mapping pages cannot be migrated.  So the corresponding

mm/Kconfig +4 -0

+
+	  Users who don't use the memory hotplug feature are fine with this
+	  option on since they don't specify movable_node boot option or they
+	  don't online memory as movable.
 
 	  Say Y here if you want to hotplug a whole node.
 	  Say N here if you want kernel to use memory on all nodes evenly.

mm/memory_hotplug.c +16 -0

index ed85fe3..6874c31 100644
@@ -31,6 +31,7 @@
 #include <linux/firmware-map.h>
 #include <linux/stop_machine.h>
 #include <linux/hugetlb.h>
+#include <linux/memblock.h>
 
 #include <asm/tlbflush.h>
 

@@ -1412,6 +1413,36 @@ static bool can_offline_normal(struct zone *zone, unsigned long nr_pages)
 }
 #endif /* CONFIG_MOVABLE_NODE */
 
+static int __init cmdline_parse_movable_node(char *p)
+{
+#ifdef CONFIG_MOVABLE_NODE
+	/*
+	 * Memory used by the kernel cannot be hot-removed because Linux
+	 * cannot migrate the kernel pages. When memory hotplug is
+	 * enabled, we should prevent memblock from allocating memory
+	 * for the kernel.
+	 *
+	 * ACPI SRAT records all hotpluggable memory ranges. But before
+	 * SRAT is parsed, we don't know about it.
+	 *
+	 * The kernel image is loaded into memory at very early time. We
+	 * cannot prevent this anyway. So on NUMA system, we set any
+	 * node the kernel resides in as un-hotpluggable.

From: Tang Chen <[email protected]>

The hot-Pluggable field in SRAT specifies which memory is hotpluggable. As we mentioned before, if hotpluggable memory is used by the kernel, it cannot be hot-removed. So memory hotplug users may want to set all hotpluggable memory in ZONE_MOVABLE so that the kernel won't use it.

Memory hotplug users may also set a node as movable node, which has ZONE_MOVABLE only, so that the whole node can be hot-removed.

But the kernel cannot use memory in ZONE_MOVABLE. By doing this, the kernel cannot use memory in movable nodes. This will cause NUMA performance down. And other users may be unhappy.

So we need a way to allow users to enable and disable this functionality. In this patch, we introduce movable_node boot option to allow users to choose to not to consume hotpluggable memory at early boot time and later we can set it as ZONE_MOVABLE.

To achieve this, the movable_node boot option will control the memblock allocation direction. That said, after memblock is ready, before SRAT is parsed, we should allocate memory near the kernel image as we explained in the previous patches. So if movable_node boot option is set, the kernel does the following:

1. After memblock is ready, make memblock allocate memory bottom up.
2. After SRAT is parsed, make memblock behave as default, allocate memory top down.

Users can specify "movable_node" in kernel commandline to enable this functionality. For those who don't use memory hotplug or who don't want to lose their NUMA performance, just don't specify anything. The kernel will work as before.

Suggested-by Kamezawa Hiroyuki <[email protected]>

Acked-by Tejun Heo <[email protected]>

Signed-off-by Tang Chen <[email protected]>

Signed-off-by Zhang Yanfei <[email protected]>

Hello, here is the v6 version. Any comments are welcome!

Quoted 1 line · Zhang Yanfei

Hello, here is the v6 version. Any comments are welcome!

Ok, I think this is as good as this feature can get without hardware support.