Allow selected nodes to be excluded from MPOL_INTERLEAVE masks

Questions:

* do we need/want a sysctl for run time modifications? IMO, no.

Quoted 4 lines · On Fri, 27 Jul 2007 16:07:57 -0400 Lee Schermerhorn <[email protected]>…

Questions:

* do we need/want a sysctl for run time modifications? IMO, no.

I can agree that runtime modification is not necessary. But applications or libnuma will not use this information ? Doing all in implicit way is enough ? (maybe enough)

BTW, could you print "nodes of XXXX are ignored in INTERLEAVE mempolicy" to /var/log/messages at boot ?

mm/page_alloc.c +4 -0

+	return 0;
+}
+early_param("no_interleave_nodes", setup_no_interleave_nodes);
+
 /* The value user specified ....changed by config */
 static int user_zonelist_order = ZONELIST_ORDER_DEFAULT;
 /* string for sysctl */

@@ -2410,8 +2435,15 @@ static int __build_all_zonelists(void *d
 		build_zonelists(pgdat);
 		build_zonelist_cache(pgdat);

Quoted 10 lines · Lee Schermerhorn

mm/page_alloc.c +4 -0

+	return 0;
+}
+early_param("no_interleave_nodes", setup_no_interleave_nodes);
+
 /* The value user specified ....changed by config */
 static int user_zonelist_order = ZONELIST_ORDER_DEFAULT;
 /* string for sysctl */

@@ -2410,8 +2435,15 @@ static int __build_all_zonelists(void *d
 		build_zonelists(pgdat);
 		build_zonelist_cache(pgdat);

mm/page_alloc.c static int __build_all_zonelists(void *d · line 2445

Quoted 10 lines

mm/page_alloc.c +7 -1

 
-		if (pgdat->node_present_pages)
+		if (pgdat->node_present_pages) {
 			node_set_state(nid, N_MEMORY);
+			/*
+			 * Only nodes with memory are valid for MPOL_INTERLEAVE,
+			 * but maybe not all of them?
+			 */
+			if (!node_isset(nid, no_interleave_nodes))
+				node_set_state(nid, N_INTERLEAVE);

			else
			 printk ....

would be better since it will only list the nodes that have memory and are excluded from interleave.

You mean instead of just listing the no_interleave_nodes node list argument which might contain memoryless nodes?

Rationale: some architectures and platforms include nodes with memory that, in some cases, should never appear in MPOL_INTERLEAVE node masks. For example, the 'sh' architecture contains a small amount of SRAM that is local to each cpu. In some applications, this memory should be reserved for explicit usage. Another example is the pseudo-node on HP ia64 platforms that is already interleaved on a cache-line granularity by hardware. Again, in some cases, we want to reserve this for explicit usage, as it has bandwidth and [average] latency characteristics quite different from the "real" nodes.

Note that allocation of fresh hugepages in response to increases in /proc/sys/vm/nr_hugepages is a form of interleaving. I would like to propose that allocate_fresh_huge_page() use the N_INTERLEAVE state as well as MPOL_INTERLEAVE. Then, one can explicity allocate hugepages on the excluded nodes, when needed, using Nish Aravamundan's per node huge page sysfs attribute. NOT in this patch.

Well, it's not so much the interleave that's the problem so much as _when_ we interleave. The problem with the interleave node mask at system init is that the kernel attempts to spread out data structures across these nodes, which results in us being completely out of memory by the time we get to userspace. After we've booted, supporting MPOL_INTERLEAVE is not so much of a problem, applications just have to be careful with their allocations.

Quoted 7 lines · On Wednesday 01 August 2007 12:16:51 Paul Mundt wrote:

Well, it's not so much the interleave that's the problem so much as _when_ we interleave. The problem with the interleave node mask at system init is that the kernel attempts to spread out data structures across these nodes, which results in us being completely out of memory by the time we get to userspace. After we've booted, supporting MPOL_INTERLEAVE is not so much of a problem, applications just have to be careful with their allocations.

I assume you got a mostly flat latency machine with a few additional small nodes for special purposes, right?

Would the problem be solved if you just had a per arch CONFIG to disable interleaving at boot? That would be really simple.

As long as interleaving is possible after boot, then yes. It's only the boot-time interleave that we would like to avoid,

Quoted 3 lines

As long as interleaving is possible after boot, then yes. It's only the boot-time interleave that we would like to avoid,

But when anybody does interleaving later it could just as easily fill up your small nodes, couldn't it?

Boot time allocations are small compared to what user space later can allocate.

And do you really want them in the normal fallback lists? The normal zone reservation heuristics probably won't work unless you put them into special low zones.

Quoted 7 lines · Andi Kleen

Quoted 3 lines

As long as interleaving is possible after boot, then yes. It's only the boot-time interleave that we would like to avoid,

But when anybody does interleaving later it could just as easily fill up your small nodes, couldn't it?

Yes, but these are in embedded environments where we have control over what the applications are doing. Most of these sorts of things are for applications where we know what sort of latency requires we have to deal with, and so the workload is very much tied to the worst-case range of nodes, or just to a particular node. We might only have certain buffers that need to be backed by faster memory as well, so while most of the application pages will come from node 0 (system memory), certain other allocations will come from other nodes. We've been experimenting with doing that through tmpfs with mpol tuning.

In the general case however it's fairly safe to include the tiny nodes as part of a larger set with a prefer policy so we don't immediately OOM.

Quoted 3 lines

Boot time allocations are small compared to what user space later can allocate.

Yes, we only want certain applications to explicitly poke at those nodes, but they do have a use case for interleave, so it is not functionality I would want to lose completely.

Quoted 5 lines

And do you really want them in the normal fallback lists? The normal zone reservation heuristics probably won't work unless you put them into special low zones.

That's something else to look at also, though I would very much like to avoid having to construct custom zonelists. it would be nice to keep things as simple and as non-invasive as possible. As far as the existing NUMA code goes, we're not quite all the way there yet in terms of supporting these things as well as we can, but it has proven to be a pretty good starting point.

Quoted 21 lines · Paul Mundt

Quoted 7 lines · Andi Kleen

Quoted 3 lines

As long as interleaving is possible after boot, then yes. It's only the boot-time interleave that we would like to avoid,

But when anybody does interleaving later it could just as easily fill up your small nodes, couldn't it?

Yes, but these are in embedded environments where we have control over what the applications are doing. Most of these sorts of things are for applications where we know what sort of latency requires we have to deal with, and so the workload is very much tied to the worst-case range of nodes, or just to a particular node. We might only have certain buffers that need to be backed by faster memory as well, so while most of the application pages will come from node 0 (system memory), certain other allocations will come from other nodes. We've been experimenting with doing that through tmpfs with mpol tuning.

In the general case however it's fairly safe to include the tiny nodes as part of a larger set with a prefer policy so we don't immediately OOM.

Quoted 6 lines

Quoted 3 lines

Boot time allocations are small compared to what user space later can allocate.

Yes, we only want certain applications to explicitly poke at those nodes, but they do have a use case for interleave, so it is not functionality I would want to lose completely.

This is why I wanted to use an "obscure boot option". I don't see this as strictly an architectural/platform issue. Rather, it's a combination of the arch/platform and how it's being used for specific applications. So, I don't see how one could accomplish this with a heuristic.

As Paul mentioned, in embedded systems, one has a bit more control over what applications are doing. In that case, I could envision a config option to specify the initial/default value for the no_interleave_nodes at kernel build time and dispense with the boot option. [Any interest

in such an option, Paul?] But for platforms like ours, that tend to run enterprise distro kernels, I need a way to specify on a per site or per installation basis, what nodes should be used. Our approach would be to document this in a "best practices" doc that the customer or, more likely, our field software specialists, would use to optimize the platform and OS config for the application.

Quoted 11 lines

Quoted 5 lines

And do you really want them in the normal fallback lists? The normal zone reservation heuristics probably won't work unless you put them into special low zones.

That's something else to look at also, though I would very much like to avoid having to construct custom zonelists. it would be nice to keep things as simple and as non-invasive as possible. As far as the existing NUMA code goes, we're not quite all the way there yet in terms of supporting these things as well as we can, but it has proven to be a pretty good starting point.

Yes, there are rumblings on the mailing list about passing just a starting [preferred] node and a node mask to the page allocator. I'm too backed up with other things to think too much about this, yet.

Lee

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

Quoted 34 lines · Lee Schermerhorn

Quoted 21 lines · Paul Mundt

Quoted 7 lines · Andi Kleen

Quoted 3 lines

As long as interleaving is possible after boot, then yes. It's only the boot-time interleave that we would like to avoid,

But when anybody does interleaving later it could just as easily fill up your small nodes, couldn't it?

Yes, but these are in embedded environments where we have control over what the applications are doing. Most of these sorts of things are for applications where we know what sort of latency requires we have to deal with, and so the workload is very much tied to the worst-case range of nodes, or just to a particular node. We might only have certain buffers that need to be backed by faster memory as well, so while most of the application pages will come from node 0 (system memory), certain other allocations will come from other nodes. We've been experimenting with doing that through tmpfs with mpol tuning.

In the general case however it's fairly safe to include the tiny nodes as part of a larger set with a prefer policy so we don't immediately OOM.

Quoted 6 lines

Quoted 3 lines

Boot time allocations are small compared to what user space later can allocate.

Yes, we only want certain applications to explicitly poke at those nodes, but they do have a use case for interleave, so it is not functionality I would want to lose completely.

This is why I wanted to use an "obscure boot option". I don't see this as strictly an architectural/platform issue. Rather, it's a combination of the arch/platform and how it's being used for specific applications. So, I don't see how one could accomplish this with a heuristic.

Quoted 4 lines

As Paul mentioned, in embedded systems, one has a bit more control over what applications are doing. In that case, I could envision a config option to specify the initial/default value for the no_interleave_nodes at kernel build time and dispense with the boot option. [Any interest

Having the interleave as a build time option won't work for some power managed memory applications. I posted an RFC a few months back and will be coming back to it in a few weeks, so take this comment with a grain of salt. But I want to be able to switch on some ACPI table entries to trigger the non-interleave boot time allocation behavior for some FBDIM based platforms. My needs are in surprising alignment with Paul's on this stuff.

--mgross

Quoted 49 lines · Mark Gross

Quoted 34 lines · Lee Schermerhorn

Quoted 21 lines · Paul Mundt

Quoted 7 lines · Andi Kleen

Quoted 3 lines

As long as interleaving is possible after boot, then yes. It's only the boot-time interleave that we would like to avoid,

But when anybody does interleaving later it could just as easily fill up your small nodes, couldn't it?

Yes, but these are in embedded environments where we have control over what the applications are doing. Most of these sorts of things are for applications where we know what sort of latency requires we have to deal with, and so the workload is very much tied to the worst-case range of nodes, or just to a particular node. We might only have certain buffers that need to be backed by faster memory as well, so while most of the application pages will come from node 0 (system memory), certain other allocations will come from other nodes. We've been experimenting with doing that through tmpfs with mpol tuning.

In the general case however it's fairly safe to include the tiny nodes as part of a larger set with a prefer policy so we don't immediately OOM.

Quoted 6 lines

Quoted 3 lines

Boot time allocations are small compared to what user space later can allocate.

Yes, we only want certain applications to explicitly poke at those nodes, but they do have a use case for interleave, so it is not functionality I would want to lose completely.

This is why I wanted to use an "obscure boot option". I don't see this as strictly an architectural/platform issue. Rather, it's a combination of the arch/platform and how it's being used for specific applications. So, I don't see how one could accomplish this with a heuristic.

Quoted 4 lines

As Paul mentioned, in embedded systems, one has a bit more control over what applications are doing. In that case, I could envision a config option to specify the initial/default value for the no_interleave_nodes at kernel build time and dispense with the boot option. [Any interest

Having the interleave as a build time option won't work for some power managed memory applications. I posted an RFC a few months back and will be coming back to it in a few weeks, so take this comment with a grain of salt. But I want to be able to switch on some ACPI table entries to trigger the non-interleave boot time allocation behavior for some FBDIM based platforms. My needs are in surprising alignment with Paul's on this stuff.

Quoted 1 line

--mgross

<snip>

Mark: you mean "boot time option", right?

When you get back to it, can you verify that this patch won't affect what you want to do in policy init [boot time interleave mask]--? ...as

long as no one specifies any no_interleave_nodes, of course. And even then, all that happens is that maybe more nodes get excluded from the boot time policy mask than you would have excluded based on ACPI info.

Until you have the ACPI table info and parsing in place [or maybe you already have this], this patch could allow you to test with the desired nodes excluded...

Quoted 11 lines · Lee Schermerhorn

Rationale: some architectures and platforms include nodes with memory that, in some cases, should never appear in MPOL_INTERLEAVE node masks. For example, the 'sh' architecture contains a small amount of SRAM that is local to each cpu. In some applications, this memory should be reserved for explicit usage. Another example is the pseudo-node on HP ia64 platforms that is already interleaved on a cache-line granularity by hardware. Again, in some cases, we want to reserve this for explicit usage, as it has bandwidth and [average] latency characteristics quite different from the "real" nodes.

Well, it's not so much the interleave that's the problem so much as _when_ we interleave. The problem with the interleave node mask at system init is that the kernel attempts to spread out data structures across these nodes, which results in us being completely out of memory by the time we get to userspace. After we've booted, supporting MPOL_INTERLEAVE is not so much of a problem, applications just have to be careful with their allocations.

The main thing is keeping the kernel away from these nodes unless it's been specifically asked to fetch some memory from there. Every page does count.

The real problem is how we want to deal with the node avoidance mask. In SLOB things presently work quite well in this regard, Christoph's slub_nodes= patch did a similar thing:

	http://marc.info/?l=linux-mm&m=118127465421877&w=2
	http://marc.info/?l=linux-mm&m=118127688911359&w=2

Quoted 8 lines

Note that allocation of fresh hugepages in response to increases in /proc/sys/vm/nr_hugepages is a form of interleaving. I would like to propose that allocate_fresh_huge_page() use the N_INTERLEAVE state as well as MPOL_INTERLEAVE. Then, one can explicity allocate hugepages on the excluded nodes, when needed, using Nish Aravamundan's per node huge page sysfs attribute. NOT in this patch.

If we can differentiate between MPOL_INTERLEAVE from the kernel's point of view, and explicit MPOL_INTERLEAVE specifiers via mbind() from userspace, that works fine for my case. However, the mpol_new() changes in this patch deny small nodes the ability to ever be included in an MPOL_INTERLEAVE policy, when it's only the kernel policy that I have a problem with.

Having said that, I do like the node states and using that to exclude a node from the system init interleave nodelist, but this still won't completely solve the tiny node problems.

mm/mempolicy.c static struct mempolicy *mpol_new(int mo · line 190

Quoted 10 lines

mm/mempolicy.c +1 -1

@@ -184,7 +184,7 @@ static struct mempolicy *mpol_new(int mo
 	case MPOL_INTERLEAVE:
 		policy->v.nodes = *nodes;
 		nodes_and(policy->v.nodes, policy->v.nodes,
-					node_states[N_MEMORY]);
+					node_states[N_INTERLEAVE]);
 		if (nodes_weight(policy->v.nodes) == 0) {
 			kmem_cache_free(policy_cache, policy);
 			return ERR_PTR(-EINVAL);

Leaving this as node_states[N_MEMORY] combined with the rest of the patch would work for me, but that sort of changes the scope of the entire patch ;-)

Quoted 6 lines · Paul Mundt

If we can differentiate between MPOL_INTERLEAVE from the kernel's point of view, and explicit MPOL_INTERLEAVE specifiers via mbind() from userspace, that works fine for my case. However, the mpol_new() changes in this patch deny small nodes the ability to ever be included in an MPOL_INTERLEAVE policy, when it's only the kernel policy that I have a problem with.

Ah, but it would only "deny small nodes" if you nominate them in the boot option. I haven't changed your heuristic in numa_policy_init. So, it will still eliminate small nodes from the boot time interleave nodemask, independent of whether or not you specify them in the no_interleave_nodes list.

Or am I missing your point?