Skip to contentSkip to conversation

per-zone kswapd process

PATCH In review Dave Hansen 9 participants 21 messages Sep 13, 2002 – Sep 18, 2002 4 messages not in the archive

Subsystems (8)
lore
Share & tools
lore
#0 lore raw

PATCH 1/1 per-zone kswapd process

This patch implements a kswapd process for each memory zone. The original code came from Bill Irwin, but the current VM is quite a bit different from the one that he wrote it for, so not much remains. The current kswapd interface is much more simple than before because there is a single waitqueue and there is a single place where it is emptied.

kswapd_can_sleep() and kswapd_balance() are simpler now that the extra pgdat level of indirection is gone.

Tested on 8-way PIII with highmem off and then 4GB support. With 4GB support, I did 20 parallel greps through a 10GB fileset while some other processes allocated and freed 1-2GB chunks of memory. That gave kswapd a good workout, and I observed it running the zone Highmem and zone Normal kswapd threads. So, it survives my torture test. It also removes more code than it adds.

include/linux/mmzone.h |    2 +
include/linux/swap.h   |    1
mm/page_alloc.c        |   11 +++++-
mm/vmscan.c            |   88 +++++++++++++++++--------------------------------
4 files changed, 42 insertions(+), 60 deletions(-)
Signature · 2 lines
Dave Hansen
[email protected]

# This is a BitKeeper generated patch for the following project:
# Project Name: Linux kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher. # This patch includes the following deltas:
# ChangeSet 1.625 -> 1.628
# include/linux/mmzone.h 1.19 -> 1.20

#	include/linux/swap.h	1.57    -> 1.58   
#	     mm/page_alloc.c	1.98    -> 1.101  
#	         mm/vmscan.c	1.102   -> 1.105  

#
# The following is the BitKeeper ChangeSet Log
# --------------------------------------------
# 02/09/12 haveblue@elm3b96.(none) 1.626

# add per-zone kswapd
# --------------------------------------------
# 02/09/12	haveblue@elm3b96.(none)	1.627
# fix some wli-indicated formatting bits
# --------------------------------------------
# 02/09/12	haveblue@elm3b96.(none)	1.628
# move waitqueue init to a more appropriate place 
# --------------------------------------------
#
diff -Nru a/include/linux/mmzone.h b/include/linux/mmzone.h
--- a/include/linux/mmzone.h	Thu Sep 12 20:24:39 2002
+++ b/include/linux/mmzone.h	Thu Sep 12 20:24:39 2002
@@ -108,6 +108,8 @@
 	unsigned long		wait_table_size;
 	unsigned long		wait_table_bits;

+ wait_queue_head_t kswapd_wait;
+
/*
* Discontig memory support fields.
*/

include/linux/swap.h +0 -1
diff -Nru a/include/linux/swap.h b/include/linux/swap.h
@@ -162,7 +162,6 @@
 extern void swap_setup(void);
 
 /* linux/mm/vmscan.c */
-extern wait_queue_head_t kswapd_wait;
 extern int try_to_free_pages(struct zone *, unsigned int, unsigned int);
 
 /* linux/mm/page_io.c */
mm/page_alloc.c +11 -2
diff -Nru a/mm/page_alloc.c b/mm/page_alloc.c
@@ -345,8 +345,15 @@
 	classzone->need_balance = 1;
 	mb();
 	/* we're somewhat low on memory, failed to find what we needed */
-	if (waitqueue_active(&kswapd_wait))
-		wake_up_interruptible(&kswapd_wait);
+	for (i = 0; zones[i] != NULL; i++) {
+		struct zone *z = zones[i];
+
+		/* We don't want to go swapping on zones that aren't actually
+		 * low.  This accounts for "incremental min" from last loop */
+		if (z->free_pages <= z->pages_low &&
+		    waitqueue_active(&z->kswapd_wait)) 
+			wake_up_interruptible(&z->kswapd_wait);
+	}
 
 	/* Go through the zonelist again, taking __GFP_HIGH into account */
 	min = 1UL << order;
@@ -874,6 +881,8 @@
 		for(i = 0; i < zone->wait_table_size; ++i)
 			init_waitqueue_head(zone->wait_table + i);
 
+		init_waitqueue_head(&zone->kswapd_wait);
+		
 		pgdat->nr_zones = j+1;
 
 		mask = (realsize / zone_balance_ratio[j]);
mm/vmscan.c +29 -57

151 lines not on this page · raw message

#1 lore raw
Quoted 2 lines · Dave Hansen

This patch implements a kswapd process for each memory zone.

I still don't see why it's per zone and not per node. It seems strange that a wee little laptop would be running two kswapds?

kswapd can get a ton of work done in the development VM and one per node would, I expect, suffice?

Also, I'm wondering why the individual kernel threads don't have their affinity masks set to make them run on the CPUs to which the zone (or zones) are local?

Isn't it the case that with this code you could end up with a kswapd on node 0 crunching on node 1's pages while a kswapd on node 1 crunches on node 0's pages?

If I'm not totally out to lunch on this, I'd have thought that a better approach would be

	int sys_kswapd(int nid)
	{
		return kernel_thread(kswapd, ...);
	}

Userspace could then set up the CPU affinity based on some topology or config information and would then parent a kswapd instance. That kswapd instance would then be bound to the CPUs which were on the node identified by `nid'.

Or something like that?

#2 lore raw
Quoted 4 lines · Andrew Morton

I still don't see why it's per zone and not per node. It seems strange that a wee little laptop would be running two kswapds? kswapd can get a ton of work done in the development VM and one per node would, I expect, suffice?

Machines without observable NUMA effects can benefit from it if it's per-zone. It also follows that if there's more than one task doing this, page replacement is less likely to block entirely. Last, but not least, when I devised it, "per-zone" was the theme.

Quoted 6 lines · Andrew Morton

Also, I'm wondering why the individual kernel threads don't have their affinity masks set to make them run on the CPUs to which the zone (or zones) are local?
Isn't it the case that with this code you could end up with a kswapd on node 0 crunching on node 1's pages while a kswapd on node 1 crunches on node 0's pages?

Without some architecture-neutral method of topology detection, there's no way to do this. A follow-up when it's there should fix it.

Quoted 11 lines · Andrew Morton

If I'm not totally out to lunch on this, I'd have thought that a better approach would be

	int sys_kswapd(int nid)
	{
		return kernel_thread(kswapd, ...);
	}

Userspace could then set up the CPU affinity based on some topology or config information and would then parent a kswapd instance. That kswapd instance would then be bound to the CPUs which were on the node identified by `nid'.
Or something like that?

I'm very very scared of handing things like that to userspace, largely because I don't trust userspace at all.

At this point, we need to enumerate nodes and provide a cpu to node correspondence to userspace, and the kernel can obey, aside from the question of "What do we do if we need to scan a node without a kswapd started yet?". I think mbligh recently got the long-needed arch code in for cpu to node... But I'm just not able to make the leap of faith that memory detection is something that can ever comfortably be given to userspace.

Cheers,
Bill
--
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/

#3 lore raw
Quoted 9 lines
Quoted 6 lines

Also, I'm wondering why the individual kernel threads don't have their affinity masks set to make them run on the CPUs to which the zone (or zones) are local?
Isn't it the case that with this code you could end up with a kswapd on node 0 crunching on node 1's pages while a kswapd on node 1 crunches on node 0's pages?

Without some architecture-neutral method of topology detection, there's no way to do this. A follow-up when it's there should fix it.

Every discontigmem arch should implement cpu_to_node, with a generic fallback mechanism that returns 0 or something. Not that we do right now, but that's easy to fix. There should also be a node_to_cpus call that returns a bitmask of which cpus are in that node.

Matt ... want to sneak in the first bit of the topology patch, or whatever lump this fell under? Seems like an appropriate juncture. We have the code already somewhere, just need to fish it out.

Quoted 15 lines
Quoted 11 lines

If I'm not totally out to lunch on this, I'd have thought that a better approach would be

	int sys_kswapd(int nid)
	{
		return kernel_thread(kswapd, ...);
	}

Userspace could then set up the CPU affinity based on some topology or config information and would then parent a kswapd instance. That kswapd instance would then be bound to the CPUs which were on the node identified by `nid'.
Or something like that?

I'm very very scared of handing things like that to userspace, largely because I don't trust userspace at all.

Quoted 7 lines

At this point, we need to enumerate nodes and provide a cpu to node correspondence to userspace, and the kernel can obey, aside from the question of "What do we do if we need to scan a node without a kswapd started yet?". I think mbligh recently got the long-needed arch code in for cpu to node... But I'm just not able to make the leap of faith that memory detection is something that can ever comfortably be given to userspace.

I don't think the userspace stuff is necessary - we can do this all in the kernel dead easily I think. Just need a couple of definitions, which are trivially small functions.

M.

A message that is not in the archive (sent off-list or not yet received): [email protected]

A message that is not in the archive (sent off-list or not yet received): [email protected]

A message that is not in the archive (sent off-list or not yet received): [email protected]

A message that is not in the archive (sent off-list or not yet received): [email protected]

#8 lore raw

Re: [PATCH] per-zone^Wnode kswapd process

Here's a per-node kswapd. It's actually per-pg_data_t, but I guess that they're equivalent. Matt is going to follow up his topology API with something to bind these to their respective nodes.

Signature · 2 lines
Dave Hansen
[email protected]
include/linux/mmzone.h +1 -0
diff -ur linux-2.5.34-mm2-clean/include/linux/mmzone.h linux-2.5.34-mm2-per-node-kswapd/include/linux/mmzone.h
@@ -168,6 +168,7 @@
 	unsigned long node_size;
 	int node_id;
 	struct pglist_data *pgdat_next;
+	wait_queue_head_t       kswapd_wait;
 } pg_data_t;
 
 extern int numnodes;
include/linux/swap.h +0 -1
diff -ur linux-2.5.34-mm2-clean/include/linux/swap.h linux-2.5.34-mm2-per-node-kswapd/include/linux/swap.h
@@ -162,7 +162,6 @@
 extern void swap_setup(void);
 
 /* linux/mm/vmscan.c */
-extern wait_queue_head_t kswapd_wait;
 extern int try_to_free_pages(struct zone *, unsigned int, unsigned int);
 
 /* linux/mm/page_io.c */
mm/page_alloc.c +8 -2
diff -ur linux-2.5.34-mm2-clean/mm/page_alloc.c linux-2.5.34-mm2-per-node-kswapd/mm/page_alloc.c
@@ -345,8 +345,12 @@
 	classzone->need_balance = 1;
 	mb();
 	/* we're somewhat low on memory, failed to find what we needed */
-	if (waitqueue_active(&kswapd_wait))
-		wake_up_interruptible(&kswapd_wait);
+	for (i = 0; zones[i] != NULL; i++) {
+		struct zone *z = zones[i];
+		if (z->free_pages <= z->pages_low &&
+		    waitqueue_active(&z->zone_pgdat->kswapd_wait))
+			wake_up_interruptible(&z->zone_pgdat->kswapd_wait);
+	}
 
 	/* Go through the zonelist again, taking __GFP_HIGH into account */
 	min = 1UL << order;
@@ -833,6 +837,8 @@
 	unsigned long zone_start_pfn = pgdat->node_start_pfn;
 
 	pgdat->nr_zones = 0;
+	init_waitqueue_head(&pgdat->kswapd_wait);
+	
 	local_offset = 0;                /* offset within lmem_map */
 	for (j = 0; j < MAX_NR_ZONES; j++) {
 		struct zone *zone = pgdat->node_zones + j;
mm/vmscan.c +14 -40

113 lines not on this page · raw message

#9 lore raw

Re: [PATCH] per-zone^Wnode kswapd process

Quoted 1 line · Dave Hansen

Here's a per-node kswapd. It's actually per-pg_data_t, but I guess that they're equivalent. Matt is going to follow up his topology API with something to bind these to their respective nodes.

Yep.. Here it is... rolled together with dave's patch.. It is only a 2 line addition. It applies cleanly on top of mm3 and topology (which I'll be resending momentarily).

Cheers!

-Matt

include/linux/mmzone.h +1 -0
diff -Nur linux-2.5.34-mm3+topo/include/linux/mmzone.h linux-2.5.34-mm3+topo+kswapd/include/linux/mmzone.h
@@ -168,6 +168,7 @@
 	unsigned long node_size;
 	int node_id;
 	struct pglist_data *pgdat_next;
+	wait_queue_head_t       kswapd_wait;
 } pg_data_t;
 
 extern int numnodes;
include/linux/swap.h +0 -1
diff -Nur linux-2.5.34-mm3+topo/include/linux/swap.h linux-2.5.34-mm3+topo+kswapd/include/linux/swap.h
@@ -162,7 +162,6 @@
 extern void swap_setup(void);
 
 /* linux/mm/vmscan.c */
-extern wait_queue_head_t kswapd_wait;
 extern int try_to_free_pages(struct zone *, unsigned int, unsigned int);
 
 /* linux/mm/page_io.c */
mm/page_alloc.c +8 -2
diff -Nur linux-2.5.34-mm3+topo/mm/page_alloc.c linux-2.5.34-mm3+topo+kswapd/mm/page_alloc.c
@@ -346,8 +346,12 @@
 	classzone->need_balance = 1;
 	mb();
 	/* we're somewhat low on memory, failed to find what we needed */
-	if (waitqueue_active(&kswapd_wait))
-		wake_up_interruptible(&kswapd_wait);
+	for (i = 0; zones[i] != NULL; i++) {
+		struct zone *z = zones[i];
+		if (z->free_pages <= z->pages_low &&
+		    waitqueue_active(&z->zone_pgdat->kswapd_wait))
+			wake_up_interruptible(&z->zone_pgdat->kswapd_wait);
+	}
 
 	/* Go through the zonelist again, taking __GFP_HIGH into account */
 	min = 1UL << order;
@@ -845,6 +849,8 @@
 	unsigned long zone_start_pfn = pgdat->node_start_pfn;
 
 	pgdat->nr_zones = 0;
+	init_waitqueue_head(&pgdat->kswapd_wait);
+	
 	local_offset = 0;                /* offset within lmem_map */
 	for (j = 0; j < MAX_NR_ZONES; j++) {
 		struct zone *zone = pgdat->node_zones + j;
mm/vmscan.c +18 -41

127 lines not on this page · raw message

#10 lore raw

Re: [PATCH] per-zone^Wnode kswapd process

In reply to Dave Hansen

As promised, here is the latest and greatest (heh) topology API patch. Should apply cleanly on top of mm3. As always, comment, criticize, and flame away!

Cheers

-Matt

include/asm-alpha/mmzone.h +0 -9
diff -Nur linux-2.5.34-mm3/include/asm-alpha/mmzone.h linux-2.5.34-mm3+topo/include/asm-alpha/mmzone.h
@@ -107,15 +107,6 @@
 #ifdef CONFIG_NUMA_SCHED
 #define NODE_SCHEDULE_DATA(nid)	(&((PLAT_NODE_DATA(nid))->schedule_data))
 #endif
-
-#ifdef CONFIG_ALPHA_WILDFIRE
-/* With wildfire assume 4 CPUs per node */
-#define cputonode(cpu)	((cpu) >> 2)
-#else
-#define cputonode(cpu)	0
-#endif /* CONFIG_ALPHA_WILDFIRE */
-
-#define numa_node_id()	cputonode(smp_processor_id())
 #endif /* CONFIG_NUMA */
 
 #endif /* CONFIG_DISCONTIGMEM */
include/asm-alpha/topology.h +14 -0
diff -Nur linux-2.5.34-mm3/include/asm-alpha/topology.h linux-2.5.34-mm3+topo/include/asm-alpha/topology.h
@@ -0,0 +1,14 @@
+#ifndef _ASM_ALPHA_TOPOLOGY_H
+#define _ASM_ALPHA_TOPOLOGY_H
+
+#ifdef CONFIG_NUMA
+#ifdef CONFIG_ALPHA_WILDFIRE
+/* With wildfire assume 4 CPUs per node */
+#define __cpu_to_node(cpu)	((cpu) >> 2)
+#endif /* CONFIG_ALPHA_WILDFIRE */
+#endif /* CONFIG_NUMA */
+
+/* Get the rest of the topology definitions */
+#include <asm-generic/topology.h>
+
+#endif /* _ASM_ALPHA_TOPOLOGY_H */
include/asm-arm/topology.h +6 -0
diff -Nur linux-2.5.34-mm3/include/asm-arm/topology.h linux-2.5.34-mm3+topo/include/asm-arm/topology.h
@@ -0,0 +1,6 @@
+#ifndef _ASM_ARM_TOPOLOGY_H
+#define _ASM_ARM_TOPOLOGY_H
+
+#include <asm-generic/topology.h>
+
+#endif /* _ASM_ARM_TOPOLOGY_H */
include/asm-cris/topology.h +6 -0
diff -Nur linux-2.5.34-mm3/include/asm-cris/topology.h linux-2.5.34-mm3+topo/include/asm-cris/topology.h
@@ -0,0 +1,6 @@
+#ifndef _ASM_CRIS_TOPOLOGY_H
+#define _ASM_CRIS_TOPOLOGY_H
+
+#include <asm-generic/topology.h>
+
+#endif /* _ASM_CRIS_TOPOLOGY_H */
include/asm-generic/topology.h +51 -0

51 lines not on this page · raw message

include/asm-i386/topology.h +92 -0

92 lines not on this page · raw message

include/asm-ia64/topology.h +6 -0
diff -Nur linux-2.5.34-mm3/include/asm-ia64/topology.h linux-2.5.34-mm3+topo/include/asm-ia64/topology.h
@@ -0,0 +1,6 @@
+#ifndef _ASM_IA64_TOPOLOGY_H
+#define _ASM_IA64_TOPOLOGY_H
+
+#include <asm-generic/topology.h>
+
+#endif /* _ASM_IA64_TOPOLOGY_H */
include/asm-m68k/topology.h +6 -0
diff -Nur linux-2.5.34-mm3/include/asm-m68k/topology.h linux-2.5.34-mm3+topo/include/asm-m68k/topology.h
@@ -0,0 +1,6 @@
+#ifndef _ASM_M68K_TOPOLOGY_H
+#define _ASM_M68K_TOPOLOGY_H
+
+#include <asm-generic/topology.h>
+
+#endif /* _ASM_M68K_TOPOLOGY_H */
include/asm-mips/topology.h +6 -0
diff -Nur linux-2.5.34-mm3/include/asm-mips/topology.h linux-2.5.34-mm3+topo/include/asm-mips/topology.h
@@ -0,0 +1,6 @@
+#ifndef _ASM_MIPS_TOPOLOGY_H
+#define _ASM_MIPS_TOPOLOGY_H
+
+#include <asm-generic/topology.h>
+
+#endif /* _ASM_MIPS_TOPOLOGY_H */
include/asm-mips64/mmzone.h +0 -2
diff -Nur linux-2.5.34-mm3/include/asm-mips64/mmzone.h linux-2.5.34-mm3+topo/include/asm-mips64/mmzone.h
@@ -28,8 +28,6 @@
 #define PLAT_NODE_DATA_LOCALNR(p, n) \
 		(((p) >> PAGE_SHIFT) - PLAT_NODE_DATA(n)->gendata.node_start_pfn)
 
-#define numa_node_id()	cputocnode(current->processor)
-
 #ifdef CONFIG_DISCONTIGMEM
 
 /*
include/asm-mips64/topology.h +11 -0
diff -Nur linux-2.5.34-mm3/include/asm-mips64/topology.h linux-2.5.34-mm3+topo/include/asm-mips64/topology.h
@@ -0,0 +1,11 @@
+#ifndef _ASM_MIPS64_TOPOLOGY_H
+#define _ASM_MIPS64_TOPOLOGY_H
+
+#include <asm/mmzone.h>
+
+#define __cpu_to_node(cpu)		(cputocnode(cpu))
+
+/* Get the rest of the topology definitions */
+#include <asm-generic/topology.h>
+
+#endif /* _ASM_MIPS64_TOPOLOGY_H */
include/asm-parisc/topology.h +6 -0
diff -Nur linux-2.5.34-mm3/include/asm-parisc/topology.h linux-2.5.34-mm3+topo/include/asm-parisc/topology.h
@@ -0,0 +1,6 @@
+#ifndef _ASM_PARISC_TOPOLOGY_H
+#define _ASM_PARISC_TOPOLOGY_H
+
+#include <asm-generic/topology.h>
+
+#endif /* _ASM_PARISC_TOPOLOGY_H */
include/asm-ppc/topology.h +6 -0
diff -Nur linux-2.5.34-mm3/include/asm-ppc/topology.h linux-2.5.34-mm3+topo/include/asm-ppc/topology.h
@@ -0,0 +1,6 @@
+#ifndef _ASM_PPC_TOPOLOGY_H
+#define _ASM_PPC_TOPOLOGY_H
+
+#include <asm-generic/topology.h>
+
+#endif /* _ASM_PPC_TOPOLOGY_H */
include/asm-ppc64/mmzone.h +0 -8
diff -Nur linux-2.5.34-mm3/include/asm-ppc64/mmzone.h linux-2.5.34-mm3+topo/include/asm-ppc64/mmzone.h
@@ -82,13 +82,5 @@
 	(ADDR_TO_MAPBASE(kaddr) + LOCAL_MAP_NR(kaddr)); \
 })
 
-#ifdef CONFIG_NUMA
-
-/* XXX grab this from the device tree - Anton */
-#define cputonode(cpu)	((cpu) >> CPU_SHIFT_BITS)
-
-#define numa_node_id()	cputonode(smp_processor_id())
-
-#endif /* CONFIG_NUMA */
 #endif /* CONFIG_DISCONTIGMEM */
 #endif /* _ASM_MMZONE_H_ */
include/asm-ppc64/topology.h +14 -0
diff -Nur linux-2.5.34-mm3/include/asm-ppc64/topology.h linux-2.5.34-mm3+topo/include/asm-ppc64/topology.h
@@ -0,0 +1,14 @@
+#ifndef _ASM_PPC64_TOPOLOGY_H
+#define _ASM_PPC64_TOPOLOGY_H
+
+#include <asm/mmzone.h>
+
+#ifdef CONFIG_NUMA
+/* XXX grab this from the device tree - Anton */
+#define __cpu_to_node(cpu)	((cpu) >> CPU_SHIFT_BITS)
+#endif /* CONFIG_NUMA */
+
+/* Get the rest of the topology definitions */
+#include <asm-generic/topology.h>
+
+#endif /* _ASM_PPC64_TOPOLOGY_H */
include/asm-s390/topology.h +6 -0
diff -Nur linux-2.5.34-mm3/include/asm-s390/topology.h linux-2.5.34-mm3+topo/include/asm-s390/topology.h
@@ -0,0 +1,6 @@
+#ifndef _ASM_S390_TOPOLOGY_H
+#define _ASM_S390_TOPOLOGY_H
+
+#include <asm-generic/topology.h>
+
+#endif /* _ASM_S390_TOPOLOGY_H */
include/asm-s390x/topology.h +6 -0
diff -Nur linux-2.5.34-mm3/include/asm-s390x/topology.h linux-2.5.34-mm3+topo/include/asm-s390x/topology.h
@@ -0,0 +1,6 @@
+#ifndef _ASM_S390X_TOPOLOGY_H
+#define _ASM_S390X_TOPOLOGY_H
+
+#include <asm-generic/topology.h>
+
+#endif /* _ASM_S390X_TOPOLOGY_H */
include/asm-sh/topology.h +6 -0
diff -Nur linux-2.5.34-mm3/include/asm-sh/topology.h linux-2.5.34-mm3+topo/include/asm-sh/topology.h
@@ -0,0 +1,6 @@
+#ifndef _ASM_SH_TOPOLOGY_H
+#define _ASM_SH_TOPOLOGY_H
+
+#include <asm-generic/topology.h>
+
+#endif /* _ASM_SH_TOPOLOGY_H */
include/asm-sparc/topology.h +6 -0
diff -Nur linux-2.5.34-mm3/include/asm-sparc/topology.h linux-2.5.34-mm3+topo/include/asm-sparc/topology.h
@@ -0,0 +1,6 @@
+#ifndef _ASM_SPARC_TOPOLOGY_H
+#define _ASM_SPARC_TOPOLOGY_H
+
+#include <asm-generic/topology.h>
+
+#endif /* _ASM_SPARC_TOPOLOGY_H */
include/asm-sparc64/topology.h +6 -0
diff -Nur linux-2.5.34-mm3/include/asm-sparc64/topology.h linux-2.5.34-mm3+topo/include/asm-sparc64/topology.h
@@ -0,0 +1,6 @@
+#ifndef _ASM_SPARC64_TOPOLOGY_H
+#define _ASM_SPARC64_TOPOLOGY_H
+
+#include <asm-generic/topology.h>
+
+#endif /* _ASM_SPARC64_TOPOLOGY_H */
include/asm-x86_64/topology.h +6 -0
diff -Nur linux-2.5.34-mm3/include/asm-x86_64/topology.h linux-2.5.34-mm3+topo/include/asm-x86_64/topology.h
@@ -0,0 +1,6 @@
+#ifndef _ASM_X86_64_TOPOLOGY_H
+#define _ASM_X86_64_TOPOLOGY_H
+
+#include <asm-generic/topology.h>
+
+#endif /* _ASM_X86_64_TOPOLOGY_H */
include/linux/mmzone.h +11 -1
diff -Nur linux-2.5.34-mm3/include/linux/mmzone.h linux-2.5.34-mm3+topo/include/linux/mmzone.h
@@ -248,13 +248,23 @@
 #define for_each_zone(zone) \
 	for (zone = pgdat_list->node_zones; zone; zone = next_zone(zone))
 
+#ifdef CONFIG_NUMA
+#define MAX_NR_MEMBLKS	BITS_PER_LONG /* Max number of Memory Blocks */
+#else /* !CONFIG_NUMA */
+#define MAX_NR_MEMBLKS	1
+#endif /* CONFIG_NUMA */
+
+#include <asm/topology.h>
+/* Returns the number of the current Node. */
+#define numa_node_id()		(__cpu_to_node(smp_processor_id()))
+
 #ifndef CONFIG_DISCONTIGMEM
 
 #define NODE_DATA(nid)		(&contig_page_data)
 #define NODE_MEM_MAP(nid)	mem_map
 #define MAX_NR_NODES		1
 
-#else /* !CONFIG_DISCONTIGMEM */
+#else /* CONFIG_DISCONTIGMEM */
 
 #include <asm/mmzone.h>
 
#11 lore raw

Re: [PATCH] per-zone^Wnode kswapd process

In reply to Dave Hansen
Quoted 5 lines · Dave Hansen

Here's a per-node kswapd. It's actually per-pg_data_t, but I guess that they're equivalent. Matt is going to follow up his topology API with something to bind these to their respective nodes.

From 64 parallel tiobench 64's (higher counts livelock in fork() etc.):

   38 root      15   0     0    0     0 RW   23.0  0.0   1:11 kswapd0
 4779 wli       22   0  4460 3588  1648 R    17.9  0.0   0:16 top

...

 4779 wli       25   0  4460 3592  1648 R    14.1  0.0   0:27 top
   38 root      15   0     0    0     0 DW    3.5  0.0   1:31 kswapd0

...

OTOH, with such a small task count, ZONE_NORMAL is the only thing feeling pressure anyway. There's also very little cpu pressure:
CPU states: 0.2% user, 6.4% system, 0.0% nice, 93.4% idle

Cheers,
Bill

#12 lore raw

Re: [PATCH] per-zone^Wnode kswapd process

Quoted 8 lines · William Lee Irwin III
Quoted 5 lines · Dave Hansen

Here's a per-node kswapd. It's actually per-pg_data_t, but I guess that they're equivalent. Matt is going to follow up his topology API with something to bind these to their respective nodes.

From 64 parallel tiobench 64's (higher counts livelock in fork() etc.):

Quoted 8 lines
   38 root      15   0     0    0     0 RW   23.0  0.0   1:11 kswapd0
 4779 wli       22   0  4460 3588  1648 R    17.9  0.0   0:16 top

...

 4779 wli       25   0  4460 3592  1648 R    14.1  0.0   0:27 top
   38 root      15   0     0    0     0 DW    3.5  0.0   1:31 kswapd0

Why do I see only one kswapd here?

Are you claiming an overall 4x improvement, or what?

I'll add some instrumentation whch tells us how many pages kswapd is reclaiming versus direct reclaim.

#13 lore raw

Re: [PATCH] per-zone^Wnode kswapd process

Quoted 6 lines · William Lee Irwin III
Quoted 6 lines

From 64 parallel tiobench 64's (higher counts livelock in fork() etc.):

   38 root      15   0     0    0     0 RW   23.0  0.0   1:11 kswapd0
 4779 wli       22   0  4460 3588  1648 R    17.9  0.0   0:16 top
...
 4779 wli       25   0  4460 3592  1648 R    14.1  0.0   0:27 top
   38 root      15   0     0    0     0 DW    3.5  0.0   1:31 kswapd0
Quoted 4 lines · Andrew Morton

Why do I see only one kswapd here?
Are you claiming an overall 4x improvement, or what? I'll add some instrumentation whch tells us how many pages kswapd is reclaiming versus direct reclaim.

I can catch the others running if I refresh more often:

   38 root      15   0     0    0     0 DW    4.8  0.0   1:57 kswapd0
   36 root      15   0     0    0     0 SW    2.7  0.0   0:16 kswapd2
 4779 wli       22   0  4476 3604  1648 R     9.2  0.0   0:58 top
   37 root      15   0     0    0     0 SW    2.6  0.0   0:16 kswapd1
   38 root      15   0     0    0     0 DW    2.9  0.0   2:12 kswapd0
   36 root      15   0     0    0     0 SW    1.8  0.0   0:22 kswapd2
 4779 wli       25   0  4476 3600  1648 R     7.4  0.0   1:18 top
   37 root      15   0     0    0     0 SW    2.7  0.0   0:21 kswapd1
 4779 wli       24   0  4476 3600  1648 R    37.5  0.0   1:49 top
   37 root      16   0     0    0     0 RW   11.1  0.0   0:23 kswapd1
 4779 wli       25   0  4476 3600  1648 R    14.1  0.0   1:51 top
   35 root      15   0     0    0     0 SW    6.9  0.0   0:24 kswapd3
   38 root      15   0     0    0     0 RW    2.9  0.0   2:29 kswapd0
   37 root      16   0     0    0     0 SW    1.4  0.0   0:28 kswapd1

etc.

Not sure about baselines. I'm happier because there's more cpu utilization. kswapd0 is relatively busy so the other ones take some load off of it. The benchmark isn't quite done yet. I think four dbench 512's in parallel might be easier to extract results from. tiobench also looks like it's getting some cpu:

procs memory io system cpu

r  b    w   swpd   free   buff  cache      bi    bo    in    cs   us  sy  id
7 3649  2      0  12516  13460 15365328   32    11209 1349  3334   3   8  90
0 3474  3      0  11216   9648 15354584   760   10333 1360  3089   2  10  88
7 3222  3      0  11872  10744 15367528   3883  8841  1371  2362   1   8  91
1 2958  2      0  12572  10304 15373820   569   10617 1347  2214   2   8  90

Cheers,
Bill

#14 lore raw

Re: [PATCH] per-zone^Wnode kswapd process

Quoted 31 lines · William Lee Irwin III

...

Quoted 4 lines · Andrew Morton

Why do I see only one kswapd here?
Are you claiming an overall 4x improvement, or what? I'll add some instrumentation whch tells us how many pages kswapd is reclaiming versus direct reclaim.

I can catch the others running if I refresh more often:

   38 root      15   0     0    0     0 DW    4.8  0.0   1:57 kswapd0
   36 root      15   0     0    0     0 SW    2.7  0.0   0:16 kswapd2
 4779 wli       22   0  4476 3604  1648 R     9.2  0.0   0:58 top
   37 root      15   0     0    0     0 SW    2.6  0.0   0:16 kswapd1
   38 root      15   0     0    0     0 DW    2.9  0.0   2:12 kswapd0
   36 root      15   0     0    0     0 SW    1.8  0.0   0:22 kswapd2
 4779 wli       25   0  4476 3600  1648 R     7.4  0.0   1:18 top
   37 root      15   0     0    0     0 SW    2.7  0.0   0:21 kswapd1
 4779 wli       24   0  4476 3600  1648 R    37.5  0.0   1:49 top
   37 root      16   0     0    0     0 RW   11.1  0.0   0:23 kswapd1
 4779 wli       25   0  4476 3600  1648 R    14.1  0.0   1:51 top
   35 root      15   0     0    0     0 SW    6.9  0.0   0:24 kswapd3
   38 root      15   0     0    0     0 RW    2.9  0.0   2:29 kswapd0
   37 root      16   0     0    0     0 SW    1.4  0.0   0:28 kswapd1
Quoted 8 lines

etc.

Not sure about baselines. I'm happier because there's more cpu utilization. kswapd0 is relatively busy so the other ones take some load off of it. The benchmark isn't quite done yet. I think four dbench 512's in parallel might be easier to extract results from. tiobench also looks like it's getting some cpu:

OK, thanks.

Could you please go into /proc/<pif_of_kswapd>/cpu and double check that each kswapd is only racking up points on the CPUs which it is supposed to be running on? As a little sanity check...

(hm. Why isn't cpus_allowed displayed from in there?)

Also, we need to double check that I'm not completely full of unmentionables, and that kswapd really is doing useful work there. I can check that.

I'll do an mm4 in a mo (as soon as I work out who did the dud patch which stops it booting) and we can see what the kwapd-versus-direct-reclaim ratio looks like.

#15 lore raw
In reply to William Lee Irwin III
Quoted 11 lines · William Lee Irwin III
Quoted 4 lines · Andrew Morton

I still don't see why it's per zone and not per node. It seems strange that a wee little laptop would be running two kswapds? kswapd can get a ton of work done in the development VM and one per node would, I expect, suffice?

Machines without observable NUMA effects can benefit from it if it's per-zone. It also follows that if there's more than one task doing this, page replacement is less likely to block entirely. Last, but not least, when I devised it, "per-zone" was the theme.

Maybe, marginally. You could pass a gfp mask to sys_kswapd to select the zones if that's really a benefit. But if this _is_ a benefit then it's a VM bug.

Because if a single kswapd cannot service three zones then it cannot service one zone. (Maybe. We need to do per-zone throttling soon to fix your OOM problems properly, but then, that shouldn't throttle kswapd).

Quoted 10 lines · Andrew Morton
Quoted 6 lines

Also, I'm wondering why the individual kernel threads don't have their affinity masks set to make them run on the CPUs to which the zone (or zones) are local?
Isn't it the case that with this code you could end up with a kswapd on node 0 crunching on node 1's pages while a kswapd on node 1 crunches on node 0's pages?

Without some architecture-neutral method of topology detection, there's no way to do this. A follow-up when it's there should fix it.

Sorry, I don't buy that.

a) It does not need to be architecture neutral.

b) You surely need a way of communicating the discovered topology to userspace anyway.

c) $EDITOR /etc/numa-layouf.conf

d) $EDITOR /etc/kswapd.conf

Quoted 13 lines · Andrew Morton
Quoted 11 lines

If I'm not totally out to lunch on this, I'd have thought that a better approach would be

      int sys_kswapd(int nid)
      {
              return kernel_thread(kswapd, ...);
      }

Userspace could then set up the CPU affinity based on some topology or config information and would then parent a kswapd instance. That kswapd instance would then be bound to the CPUs which were on the node identified by `nid'.
Or something like that?

Quoted 2 lines

I'm very very scared of handing things like that to userspace, largely because I don't trust userspace at all.

Me either. I've seen workloads in which userspace consumes over 50% of the CPU resources. It should be banned!

Quoted 4 lines

At this point, we need to enumerate nodes and provide a cpu to node correspondence to userspace, and the kernel can obey, aside from the question of "What do we do if we need to scan a node without a kswapd started yet?".

kswapd is completely optional. Put a `do_exit(0)' into the current
one and watch. You'll get crappy dbench numbers, but it stays up.

Quoted 4 lines

I think mbligh recently got the long-needed arch code in
for cpu to node... But I'm just not able to make the leap of faith that memory detection is something that can ever comfortably be given to userspace.

A simple syscall which alows you to launch a kswapd instance against a group of zones on any group of CPUs provides complete generality and flexibility to userspace. And it is architecture neutral.

If it really is incredibly hard to divine the topology from userspace then you need to fix that up. Provide the topology to userspace. Which has the added benefit of providing, umm, the topology to userspace ;)

#16 lore raw
Quoted 10 lines

Sorry, I don't buy that.

a) It does not need to be architecture neutral.

b) You surely need a way of communicating the discovered topology to userspace anyway.

c) $EDITOR /etc/numa-layouf.conf

d) $EDITOR /etc/kswapd.conf

I guess you could do that, but it seems overly complicated to me.

Quoted 5 lines
Quoted 4 lines

I think mbligh recently got the long-needed arch code in
for cpu to node... But I'm just not able to make the leap of faith that memory detection is something that can ever comfortably be given to userspace.

Quoted 7 lines

A simple syscall which alows you to launch a kswapd instance against a group of zones on any group of CPUs provides complete generality and flexibility to userspace. And it is architecture neutral.

If it really is incredibly hard to divine the topology from userspace then you need to fix that up. Provide the topology to userspace. Which has the added benefit of providing, umm, the topology to userspace ;)

Can we make a simple default of 1 per node, which is what 99% of people want, and then make it more complicated later if people complain? It's really pretty easy:

for (node = 0; node < numnodes; ++node) {
	kswapd = kick_off_kswapd_for_node(node);
	kswapd->cpus_allowed = node_to_cpus(node);
}

Or whatever the current cpus_allowed method is. All we seem to need is node_to_cpus ... I can give that to you tommorow with no problem, it's trivial.

M.

#17 lore raw
Quoted 10 lines · Martin J. Bligh

..
Can we make a simple default of 1 per node, which is what 99% of people want, and then make it more complicated later if people complain? It's really pretty easy:

for (node = 0; node < numnodes; ++node) {
        kswapd = kick_off_kswapd_for_node(node);
        kswapd->cpus_allowed = node_to_cpus(node);
}

Seems sane.

Quoted 3 lines

Or whatever the current cpus_allowed method is. All we seem to need is node_to_cpus ... I can give that to you tommorow with no problem, it's trivial.

Tomorrow sounds too early - it'd be nice to get some before-n-after performance testing to go along with that patch ;)

#18 lore raw
In reply to William Lee Irwin III
Quoted 4 lines · William Lee Irwin III

Machines without observable NUMA effects can benefit from it if it's per-zone. It also follows that if there's more than one task doing this, page replacement is less likely to block entirely. Last, but not least, when I devised it, "per-zone" was the theme.

It will also increase the amount of disk head thrashing surely ?

#19 lore raw
Quoted 4 lines · William Lee Irwin III
Quoted 4 lines

Machines without observable NUMA effects can benefit from it if it's per-zone. It also follows that if there's more than one task doing this, page replacement is less likely to block entirely. Last, but not least, when I devised it, "per-zone" was the theme.

Quoted 1 line · Alan Cox

It will also increase the amount of disk head thrashing surely ?

I doubt it. Writeout isn't really supposed to happen there in 2.4 either, except under duress. OTOH I've not been doing much with this directly since rmap10c.

Cheers,
Bill
--
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/

#20 lore raw

PATCH 1/1 recognize MAP_LOCKED in mmap() call

Andrew, at the current time an mmap() ignores a MAP_LOCKED passed to it. The only way we can get VM_LOCKED associated with the newly created VMA is to have previously called mlockall() on the process which sets the mm->def_flags != VM_LOCKED or subsequently call mlock() on the newly created VMA.

The attached patch checks for MAP_LOCKED being passed and if so checks the capabilities of the process. Limit checks were already in place.

Signature · 17 lines
-- Hubertus Franke  ([email protected])

--------------------------------< PATCH >------------------------------
--- linux-2.5.35/mm/mmap.c	Wed Sep 18 11:12:13 2002
+++ linux-2.5.35-fix/mm/mmap.c	Wed Sep 18 11:44:32 2002
@@ -461,6 +461,11 @@
 	 */
 	vm_flags = calc_vm_flags(prot,flags) | mm->def_flags | VM_MAYREAD | VM_MAYWRITE | VM_MAYEXEC;
 
+	if (flags & MAP_LOCKED) {
+		if (!capable(CAP_IPC_LOCK))
+			return -EPERM;
+		vm_flags |= VM_LOCKED;
+	}
 	/* mlock MCL_FUTURE? */
 	if (vm_flags & VM_LOCKED) {
 		unsigned long locked = mm->locked_vm << PAGE_SHIFT;
mm/mmap.c +5 -0
@@ -461,6 +461,11 @@
 	 */
 	vm_flags = calc_vm_flags(prot,flags) | mm->def_flags | VM_MAYREAD | VM_MAYWRITE | VM_MAYEXEC;
 
+	if (flags & MAP_LOCKED) {
+		if (!capable(CAP_IPC_LOCK))
+			return -EPERM;
+		vm_flags |= VM_LOCKED;
+	}
 	/* mlock MCL_FUTURE? */
 	if (vm_flags & VM_LOCKED) {
 		unsigned long locked = mm->locked_vm << PAGE_SHIFT;
#21 lore raw

Re: [PATCH] recognize MAP_LOCKED in mmap() call

Quoted 9 lines · Hubertus Franke

Andrew, at the current time an mmap() ignores a MAP_LOCKED passed to it. The only way we can get VM_LOCKED associated with the newly created VMA is to have previously called mlockall() on the process which sets the mm->def_flags != VM_LOCKED or subsequently call mlock() on the newly created VMA.

The attached patch checks for MAP_LOCKED being passed and if so checks the capabilities of the process. Limit checks were already in place.

Looks sane, thanks.

It appears that MAP_LOCKED is a Linux-special, so presumably it _used_ to work. I wonder when it broke?

You patch applies to 2.4 as well; it would be useful to give that a sanity test and send a copy to Marcelo.

(SuS really only anticipates that mmap needs to look at prior mlocks in force against the address range. It also says

Process memory locking does apply to shared memory regions,

and we don't do that either. I think we should; can't see why SuS requires this.)

#22 lore raw
In reply to William Lee Irwin III
Quoted 8 lines · William Lee Irwin III
Quoted 4 lines · Andrew Morton

I still don't see why it's per zone and not per node. It seems strange that a wee little laptop would be running two kswapds? kswapd can get a ton of work done in the development VM and one per node would, I expect, suffice?

Machines without observable NUMA effects can benefit from it if it's per-zone.

How?

Signature · 1 line
Daniel
#23 lore raw
Quoted 4 lines · Andrew Morton
Quoted 4 lines
Quoted 4 lines

I still don't see why it's per zone and not per node. It seems strange that a wee little laptop would be running two kswapds? kswapd can get a ton of work done in the development VM and one per node would, I expect, suffice?

Quoted 2 lines · William Lee Irwin III
Quoted 2 lines

Machines without observable NUMA effects can benefit from it if it's per-zone.

Quoted 1 line · Daniel Phillips

How?

The notion was that some level of parallelism would be bestowed on the single-node case by using separate worker threads on a per-zone basis, as they won't have more than one node to spawn worker threads for at all.

This notion apparently got shot down somewhere, and I don't care to rise to its defense. I've lost enough debates this release to know better than to try.

Bill

#24 lore raw
Quoted 3 lines · William Lee Irwin III

This notion apparently got shot down somewhere, and I don't care to rise to its defense. I've lost enough debates this release to know better than to try.

Don't worry about this, there are bigger fish around, lower hanging sea fruit, so to say. ;)

Rik

Signature · 5 lines
Bravely reimplemented by the knights who say "NIH".

http://www.surriel.com/		http://distro.conectiva.com/

Spamtraps of the month:  [email protected] [email protected]