mm: implement swap prefetching

Andrew et al

I'm resubmitting the swap prefetching patch for inclusion in -mm and hopefully mainline.

After you removed it from -mm there were some people that described the benefits it afforded their workloads. -mm being ever so slightly quieter at the moment please reconsider.

The amount prefetched in each group is configurable via the tunable in /proc/sys/vm/swap_prefetch. This is set to a value based on memory size. When laptop_mode is enabled it prefetches in ten times larger blocks to minimise the time spent reading.

===================================================================

mm/swap_prefetch.c new file +26 -0

@@ -0,0 +1,431 @@
+/*
+ * linux/mm/swap_prefetch.c
+ *
+ * Copyright (C) 2005 Con Kolivas
+ *
+ * Written by Con Kolivas <[email protected]>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/fs.h>
+#include <linux/swap.h>
+#include <linux/ioprio.h>
+#include <linux/kthread.h>
+#include <linux/pagemap.h>
+#include <linux/syscalls.h>
+#include <linux/writeback.h>
+
+/* Time to delay prefetching if vm is busy or prefetching unsuccessful */
+#define PREFETCH_DELAY	(HZ * 5)
+/* Time between attempting prefetching when vm is idle */
+#define PREFETCH_INTERVAL (HZ)
+
+/* sysctl - how many SWAP_CLUSTER_MAX pages to prefetch at a time */

mm/swap_prefetch.c new file +3 -0

+};
 
+struct swapped_entry {
+	swp_entry_t		swp_entry;

mm/swap_prefetch.c new file +4 -0

+
+/*
+ * Accounting is sloppy on purpose. As adding and removing entries from the
+ * list happens during swapping in and out we don't want to be spinning on

mm/swap_prefetch.c new file +5 -0

+		entry = list_entry(swapped.list.next,
+			struct swapped_entry, swapped_list);
+		radix_tree_delete(&swapped.swap_tree, entry->swp_entry.val);
+		list_del(&entry->swapped_list);
+		swapped.count--;

mm/swap_prefetch.c new file +27 -0

+static inline int high_zone(struct zone *zone)
+{
+	if (zone == NULL)
+		return 0;
+	return is_highmem(zone);
+}
+
+/*
+ * Find the zone with the most free pages, recheck the watermarks and
+ * then directly allocate the ram. We don't want prefetch to use
+ * __alloc_pages and go calling on reclaim.
+ */
+static struct page *prefetch_get_page(void)
+{
+	struct zone *zone = NULL, *z;
+	struct page *page = NULL;
+	struct zonelist *zonelist;
+	long most_free = 0;
+
+	for_each_zone(z) {
+		long free;
+
+		if (z->present_pages == 0)
+			continue;
+
+		/* We don't prefetch into DMA */
+		if (zone_idx(z) == ZONE_DMA)

mm/swap_prefetch.c new file +32 -0

+/*
+ * We want to be absolutely certain it's ok to start prefetching.
+ */
+static int prefetch_suitable(void)
+{
+	struct page_state ps;
+	unsigned long limit;
+	struct zone *z;
+	int ret = 0;
+
+	/* Purposefully racy and might return false positive which is ok */
+	if (__test_and_clear_bit(0, &swapped.busy))
+		goto out;
+
+	temp_free = 0;
+	/*
+	 * Have some hysteresis between where page reclaiming and prefetching
+	 * will occur to prevent ping-ponging between them.
+	 */
+	for_each_zone(z) {
+		unsigned long free;
+
+		if (z->present_pages == 0)
+			continue;
+		free = z->free_pages;
+		if (z->pages_high * 3 > free)
+			goto out;
+		temp_free += free;
+	}
+
+	/*
+	 * We check to see that pages are not being allocated elsewhere

mm/swap_prefetch.c new file +10 -0

+
+static int kprefetchd(void *__unused)
+{
+	set_user_nice(current, 19);
+	/* Set ioprio to lowest if supported by i/o scheduler */
+	sys_ioprio_set(IOPRIO_WHO_PROCESS, 0, IOPRIO_CLASS_IDLE);
+
+	do {
+		enum trickle_return prefetched;
+

Quoted 3 lines · Con Kolivas

After you removed it from -mm there were some people that described the benefits it afforded their workloads. -mm being ever so slightly quieter at the moment please reconsider.

I wish I could convince myself this is sufficiently beneficial..

I've been running 2.6.15-rc2-mm2 on my main workstation (x86, 2G) since whenever. (Am lazy, haven't gotten around to upgrading that machine). It has swap prefetch.

I can't say I noticed any difference, although I did turn it off in /proc a few reboots ago because it was irritating me for some reason which I forget (sorry).

One thing about 2.6.15-rc2-mm2 is that the so' and si' columns in `vmstat' always read zero. I don't know whether that bug is due to the prefetch patch or not.

Quoted 5 lines

The amount prefetched in each group is configurable via the tunable in /proc/sys/vm/swap_prefetch. This is set to a value based on memory size. When laptop_mode is enabled it prefetches in ten times larger blocks to minimise the time spent reading.

That's incomprehensible, sorry.

I think it'd be much clearer if the thing was called swap_prefetch_kbytes or swap_prefetch_mbytes or (worse) swap_prefetch_pages - putting the units in the name really helps clarify things.

And if such a change is made, the internal variable should also be renamed.
Right now it's "swap_prefetch", which sounds like a boolean.

Documentation/sysctl/vm.txt Time is set in seconds and set by defaul · line 189

Quoted 7 lines

Documentation/sysctl/vm.txt +6 -0

+swap_prefetch
+
+This is the amount of data prefetched per prefetching interval when
+swap prefetching is compiled in. The value means multiples of 128K,
+except when laptop_mode is enabled and then it is ten times larger.
+Setting it to 0 disables prefetching entirely.

What does "ten times larger" mean? If laptop_mode, this thing is in units of 1280 kbytes and if !laptop_mode it's in units of 128 kbytes?

If so (or if not), this tunable is quite obscure and hard-to-understand. Can you find a way to make this more user-friendly?

mm/swap_prefetch.c line 58

Quoted 3 lines

mm/swap_prefetch.c new file +3 -0

+/* Last total free pages */
+static unsigned long last_free = 0;
+static unsigned long temp_free = 0;

Unneeded initialisation.

Review

Quoted 2 lines

(quoted diff) +2 -0

+	if (unlikely(!spin_trylock(&swapped.lock)))
+		goto out;

hm, spin_trylock() should internally do unlikely(), but it doesn't. (It's a bit of a mess, too).

mm/swap_prefetch.c line 196

Quoted 7 lines

mm/swap_prefetch.c new file +7 -0

+		/* Select the zone with the most free ram preferring high */
+		if ((free > most_free && (!high_zone(zone) || high_zone(z))) ||
+			(!high_zone(zone) && high_zone(z))) {
+				most_free = free;
+				zone = z;
+		}
+	}

<stares at the above expression for three minutes>

I think it'll always select ZONE_HIGHMEM no matter what. Users of 1G x86 boxes not happy.

mm/swap_prefetch.c line 267

Quoted 4 lines

mm/swap_prefetch.c new file +4 -0

+static inline unsigned long prefetch_pages(void)
+{
+	return (SWAP_CLUSTER_MAX * swap_prefetch * (1 + 9 * !!laptop_mode));
+}

I don't think this should be done in-kernel. There's a nice script to start and stop laptop mode. We can make this decision in that script.

mm/swap_prefetch.c line 310

Quoted 7 lines

mm/swap_prefetch.c new file +7 -0

+	if (last_free) {
+		if (temp_free + SWAP_CLUSTER_MAX < last_free) {
+			last_free = temp_free;
+			goto out;
+		}
+	} else
+		last_free = temp_free;

What is the actual threshold rate here? SWAP_CLUSTER_MAX/(how fast your CPU is)? Seems a bit vague?

mm/swap_prefetch.c line 312

Quoted 1 line

mm/swap_prefetch.c new file +1 -0

+	get_page_state(&ps);

get_page_state() can be super-expensive. How frequently is this called?

Review

Quoted 2 lines

(quoted diff) +2 -0

+		case TRICKLE_SUCCESS:
+			last_free = temp_free;

This `last_free' thing is really confusing. It's central to the algorithms yet its name is largely meaningless. last_free *what*? It seems to mean "total number of free pages on the last prefetching pass", yes? Wanna think of a better name and a better comment for it?

Quoted 6 lines · Andrew Morton

Review

Quoted 2 lines · Con Kolivas

(quoted diff) +2 -0

+	if (unlikely(!spin_trylock(&swapped.lock)))
+		goto out;

hm, spin_trylock() should internally do unlikely(), but it doesn't. (It's a bit of a mess, too).

Good point. Perhaps I should submit a separate patch for this instead.

Quoted 4 lines

+/*
+ * How many pages to prefetch at a time. We prefetch SWAP_CLUSTER_MAX *
+ * swap_prefetch per PREFETCH_INTERVAL, but prefetch ten times as much at a
+ * time in laptop_mode to minimise the time we keep the disk spinning.

mm/swap_prefetch.c line 267

Quoted 5 lines

+ */

mm/swap_prefetch.c new file +4 -0

+static inline unsigned long prefetch_pages(void)
+{
+     return (SWAP_CLUSTER_MAX * swap_prefetch * (1 + 9 * !!laptop_mode));
+}

I don't think this should be done in-kernel. There's a nice script to start and stop laptop mode. We can make this decision in that script.

Quoted 6 lines

mm/swap_prefetch.c line 58

Quoted 4 lines

mm/swap_prefetch.c new file +3 -0

+/* Last total free pages */
+static unsigned long last_free = 0;
+static unsigned long temp_free = 0;

Unneeded initialisation.

Very first use of both of these variables depends on them being initialised.

Andrew et al

I'm resubmitting the swap prefetching patch for inclusion in -mm and hopefully mainline. After you removed it from -mm there were some people that described the benefits it afforded their workloads. -mm being ever so slightly quieter at the moment please reconsider.

Cheers,
Con
---
This patch implements swap prefetching when the vm is relatively idle and there is free ram available. The code is based on some early work by Thomas Schlichter.

It introduces global cacheline bouncing in pagecache allocation and removal

Quoted 6 lines · Con Kolivas

Andrew et al

I'm resubmitting the swap prefetching patch for inclusion in -mm and hopefully mainline. After you removed it from -mm there were some people that described the benefits it afforded their workloads. -mm being ever so slightly quieter at the moment please reconsider.

I have a few comments.

prefetch_get_page is doing funny things with zones and nodes / zonelists (eg. 'We don't prefetch into DMA' meaning something like 'this only works on i386 and x86-64').

buffered_rmqueue, zone_statistics, etc really should to stay static to page_alloc.

It is completely non NUMA or cpuset-aware so it will likely allocate memory in the wrong node, and will cause cpuset tasks that have their memory swapped out to get it swapped in again on other parts of the machine (ie. breaks cpuset's memory partitioning stuff).

It introduces global cacheline bouncing in pagecache allocation and removal and page reclaim paths, also low watermark failure is quite common in normal operation, so that is another global cacheline write in page allocation path.

Why bother with the trylocks? On many architectures they'll RMW the cacheline anyway, so scalability isn't going to be much improved (or do you see big lock contention?)

Aside from those issues, I think the idea has is pretty cool... but there are a few things that get to me:

- it is far more common to reclaim pages from other mappings (not swap). Shouldn't they have the same treatment? Would that be more worthwhile?

- when is a system _really_ idle? what if we want it to stay idle (eg. laptops)? what if some block devices or swap devices are busy, or memory is continually being allocated and freed and/or pagecache is being created and truncated but we still want to prefetch?

- for all its efforts, it will still interact with page reclaim by putting pages on the LRU and causing them to be cycled.

- on bursty loads, this cycling could happen a bit. and more reads on the swap devices.

- in a sense it papers over page reclaim problems that shouldn't be so bad in the first place (midnight cron). On the other hand, I can see how it solves this issue nicely.

Quoted 1 line · Nick Piggin

I have a few comments.

Thanks.

Quoted 4 lines

prefetch_get_page is doing funny things with zones and nodes / zonelists (eg. 'We don't prefetch into DMA' meaning something like 'this only works on i386 and x86-64').

Hrm? It's just a generic thing to do; I'm not sure I follow why it's i386 and x86-64 only. Every architecture has ZONE_NORMAL so it will prefetch there.

Quoted 3 lines

buffered_rmqueue, zone_statistics, etc really should to stay static to page_alloc.

I can have an even simpler version of buffered_rmqueue specifically for swap prefetch, but I didn't want to reproduce code unnecessarily, nor did I want a page allocator outside page_alloc.c or swap_prefetch only code placed in page_alloc. The higher level page allocators do too much and they test to see if we should reclaim (which we never want to do) or allocate too many pages. It is the only code "cost" when swap prefetch is configured off. I'm open to suggestions?

Quoted 6 lines

It is completely non NUMA or cpuset-aware so it will likely allocate memory in the wrong node, and will cause cpuset tasks that have their memory swapped out to get it swapped in again on other parts of the machine (ie. breaks cpuset's memory partitioning stuff).

Quoted 4 lines

It introduces global cacheline bouncing in pagecache allocation and removal and page reclaim paths, also low watermark failure is quite common in normal operation, so that is another global cacheline write in page allocation path.

None of these issues is going to remotely the target audience. If the issue is how scalable such a change can be then I cannot advocate making the code smart and complex enough to be numa and cpuset aware.. but then that's never going to be the target audience. It affects a particular class of user which happens to be quite a large population not affected by complex memory hardware.

Quoted 4 lines

Why bother with the trylocks? On many architectures they'll RMW the cacheline anyway, so scalability isn't going to be much improved (or do you see big lock contention?)

Rather than scalability concerns per se the trylock is used as yet another (admittedly rarely hit) way of defining busy.

Quoted 6 lines

Aside from those issues, I think the idea has is pretty cool... but there are a few things that get to me:

- it is far more common to reclaim pages from other mappings (not swap). Shouldn't they have the same treatment? Would that be more worthwhile?

I don't know. Swap is the one that affect ordinary desktop users in magnitudes that embarrass perceived performance beyond belief. I didn't have any other uses for this code in mind.

Quoted 4 lines

- when is a system _really_ idle? what if we want it to stay idle (eg. laptops)? what if some block devices or swap devices are busy, or memory is continually being allocated and freed and/or pagecache is being created and truncated but we still want to prefetch?

The code is pretty aggressive at defining busy. It looks for pretty much all of those and it prefetches till it stops then allowing idle to occur again. Opting out of prefetching whenever there is doubt seems reasonable to me.

Quoted 6 lines

- for all its efforts, it will still interact with page reclaim by putting pages on the LRU and causing them to be cycled.

- on bursty loads, this cycling could happen a bit. and more reads on the swap devices.

Theoretically yes I agree. The definition of busy is so broad that prevents it prefetching that it is not significant.

Quoted 4 lines

- in a sense it papers over page reclaim problems that shouldn't be so bad in the first place (midnight cron). On the other hand, I can see how it solves this issue nicely.

I doubt any audience that will care about scalability and complex memory configurations would knowingly enable it so it costs them virtually nothing for the relatively unintrusive code to be there. It's configurable and helps a unique problem that affects most users who are not in the complex hardware group. I was not advocating it being enabled by default, but last time it was in -mm akpm suggested doing that to increase its testing - while in -mm.

Quoted 8 lines · Con Kolivas

Quoted 3 lines · Nick Piggin

prefetch_get_page is doing funny things with zones and nodes / zonelists (eg. 'We don't prefetch into DMA' meaning something like 'this only works on i386 and x86-64').

Hrm? It's just a generic thing to do; I'm not sure I follow why it's i386 and x86-64 only. Every architecture has ZONE_NORMAL so it will prefetch there.

I don't think every architecture has ZONE_NORMAL.

Quoted 10 lines

Quoted 2 lines

buffered_rmqueue, zone_statistics, etc really should to stay static to page_alloc.

I can have an even simpler version of buffered_rmqueue specifically for swap prefetch, but I didn't want to reproduce code unnecessarily, nor did I want a page allocator outside page_alloc.c or swap_prefetch only code placed in page_alloc. The higher level page allocators do too much and they test to see if we should reclaim (which we never want to do) or allocate too many pages. It is the only code "cost" when swap prefetch is configured off. I'm open to suggestions?

If you omit __GFP_WAIT and already test the watermarks yourself it should be OK.

Quoted 10 lines

Quoted 9 lines

It is completely non NUMA or cpuset-aware so it will likely allocate memory in the wrong node, and will cause cpuset tasks that have their memory swapped out to get it swapped in again on other parts of the machine (ie. breaks cpuset's memory partitioning stuff).

It introduces global cacheline bouncing in pagecache allocation and removal and page reclaim paths, also low watermark failure is quite common in normal operation, so that is another global cacheline write in page allocation path.

Quoted 6 lines

None of these issues is going to remotely the target audience. If the issue is how scalable such a change can be then I cannot advocate making the code smart and complex enough to be numa and cpuset aware.. but then that's never going to be the target audience. It affects a particular class of user which happens to be quite a large population not affected by complex memory hardware.

Workstations can have 2 or more dual core CPUs with multiple threads or NUMA these days. Desktops and laptops will probably eventually gain more cores and threads too.

Quoted 6 lines

Quoted 3 lines

Why bother with the trylocks? On many architectures they'll RMW the cacheline anyway, so scalability isn't going to be much improved (or do you see big lock contention?)

Rather than scalability concerns per se the trylock is used as yet another (admittedly rarely hit) way of defining busy.

They just seem to complicate the code for apparently little gain.

Quoted 4 lines

The code is pretty aggressive at defining busy. It looks for pretty much all of those and it prefetches till it stops then allowing idle to occur again. Opting out of prefetching whenever there is doubt seems reasonable to me.

What if you want to prefetch when there is slight activity going on though?

What if your pagecache has filled memory with useless stuff (which would appear to be the case with updatedb).

What if you don't want to prefetch in
laptop mode at all?

Quoted 8 lines

Quoted 5 lines

- for all its efforts, it will still interact with page reclaim by putting pages on the LRU and causing them to be cycled.

- on bursty loads, this cycling could happen a bit. and more reads on the swap devices.

Theoretically yes I agree. The definition of busy is so broad that prevents it prefetching that it is not significant.

Not if the workload is very bursty.

Quoted 11 lines

Quoted 3 lines

- in a sense it papers over page reclaim problems that shouldn't be so bad in the first place (midnight cron). On the other hand, I can see how it solves this issue nicely.

I doubt any audience that will care about scalability and complex memory configurations would knowingly enable it so it costs them virtually nothing for the relatively unintrusive code to be there. It's configurable and helps a unique problem that affects most users who are not in the complex hardware group. I was not advocating it being enabled by default, but last time it was in -mm akpm suggested doing that to increase its testing - while in -mm.

If it is in core mm then I would very much like to see it adhere to how everything else works, and attempt to be scalable and generalised.

Any code in a core system is intrusive by definition because it simply adds to the amount of work that needs to be done when maintaining the thing or trying to understand how things work, debugging people's badly behaving workloads, etc.

If it is going to be off by default, why couldn't they echo 10 > /proc/sys/vm/swappiness rather than turning it on?

Quoted 8 lines · Nick Piggin

Quoted 6 lines · Con Kolivas

Quoted 3 lines · Nick Piggin

prefetch_get_page is doing funny things with zones and nodes / zonelists (eg. 'We don't prefetch into DMA' meaning something like 'this only works on i386 and x86-64').

Quoted 5 lines

Quoted 3 lines

Hrm? It's just a generic thing to do; I'm not sure I follow why it's i386 and x86-64 only. Every architecture has ZONE_NORMAL so it will prefetch there.

I don't think every architecture has ZONE_NORMAL.

!ZONE_DMA they all have, no?

Quoted 2 lines

If you omit __GFP_WAIT and already test the watermarks yourself it should be OK.

Ok.

Quoted 3 lines

Workstations can have 2 or more dual core CPUs with multiple threads or NUMA these days. Desktops and laptops will probably eventually gain more cores and threads too.

While I am aware of the hardware changes out there I still doubt the scalability issues you're concerned about affect a desktop. The code cost and complexity will increase substantially yet I'm not sure that will be for any gain to the targetted users.

Quoted 5 lines

Quoted 5 lines

Quoted 4 lines

Why bother with the trylocks? On many architectures they'll RMW the cacheline anyway, so scalability isn't going to be much improved (or do you see big lock contention?)

Quoted 4 lines

Quoted 2 lines

Rather than scalability concerns per se the trylock is used as yet another (admittedly rarely hit) way of defining busy.

They just seem to complicate the code for apparently little gain.

No biggie; I'll drop them.

Quoted 7 lines

Quoted 5 lines

The code is pretty aggressive at defining busy. It looks for pretty much all of those and it prefetches till it stops then allowing idle to occur again. Opting out of prefetching whenever there is doubt seems reasonable to me.

What if you want to prefetch when there is slight activity going on though?

I don't. I want this to not cost us anything during any activity.

Quoted 3 lines

What if your pagecache has filled memory with useless stuff (which would appear to be the case with updatedb).

There is no way the vm will ever be smart enough to say "this is crap, throw it out and prefetch some good stuff", so it doesn't matter.

Quoted 6 lines

Quoted 6 lines

Quoted 5 lines

- for all its efforts, it will still interact with page reclaim by putting pages on the LRU and causing them to be cycled.

- on bursty loads, this cycling could happen a bit. and more reads on the swap devices.

Quoted 4 lines

Quoted 2 lines

Theoretically yes I agree. The definition of busy is so broad that prevents it prefetching that it is not significant.

Not if the workload is very bursty.

It's an either/or for prefetching; I don't see a workaround, just some sane balance.

Quoted 4 lines

Any code in a core system is intrusive by definition because it simply adds to the amount of work that needs to be done when maintaining the thing or trying to understand how things work, debugging people's badly behaving workloads, etc.

I'm open to code suggestions and appreciate any outside help.

Quoted 3 lines

If it is going to be off by default, why couldn't they echo 10 > /proc/sys/vm/swappiness rather than turning it on?

Because we still swap no matter what the sysctl setting is, which makes it even more useful in my opinion for those who aggressively set this tunable.

Quoted 11 lines · Con Kolivas

Quoted 10 lines · Nick Piggin

Quoted 8 lines · Con Kolivas

Quoted 3 lines · Nick Piggin

prefetch_get_page is doing funny things with zones and nodes / zonelists (eg. 'We don't prefetch into DMA' meaning something like 'this only works on i386 and x86-64').

Hrm? It's just a generic thing to do; I'm not sure I follow why it's i386 and x86-64 only. Every architecture has ZONE_NORMAL so it will prefetch there.

Quoted 3 lines

Quoted 1 line

I don't think every architecture has ZONE_NORMAL.

!ZONE_DMA they all have, no?

Don't think so. IIRC ppc64 has only ZONE_DMA although may have picked up DMA32 now (/me boots the G5).

Quoted 4 lines

Quoted 3 lines

Workstations can have 2 or more dual core CPUs with multiple threads or NUMA these days. Desktops and laptops will probably eventually gain more cores and threads too.

Quoted 4 lines

While I am aware of the hardware changes out there I still doubt the scalability issues you're concerned about affect a desktop. The code cost and complexity will increase substantially yet I'm not sure that will be for any gain to the targetted users.

Possibly. Why wouldn't you want swap prefetching on servers though? Especially on some kind of shell server, or other internet server where load could be really varied.

Quoted 4 lines

Quoted 2 lines

What if you want to prefetch when there is slight activity going on though?

I don't. I want this to not cost us anything during any activity.

So if you have say some networking running (p2p or something), then it may not ever prefetch?

Quoted 5 lines

Quoted 2 lines

What if your pagecache has filled memory with useless stuff (which would appear to be the case with updatedb).

There is no way the vm will ever be smart enough to say "this is crap, throw it out and prefetch some good stuff", so it doesn't matter.

It can do a lot better about throwing out updatedb type stuff.

Actually I had thought the point of this was to page in stuff after the updatedb run, but it would appear that it won't do this because updatedb will leave the pagecache full...

Quoted 1 line

I'm open to code suggestions and appreciate any outside help.

Hopefully you have a bit to go on.

I still see difficult problems that
I'm not sure how can be solved.

Quoted 6 lines

Quoted 2 lines

If it is going to be off by default, why couldn't they echo 10 > /proc/sys/vm/swappiness rather than turning it on?

Because we still swap no matter what the sysctl setting is, which makes it even more useful in my opinion for those who aggressively set this tunable.

Sounds like we need to do more basic VM tuning as well.

Andrew I think I see why your G5 didn't see any benefit with swap prefetching.

Quoted 11 lines · Con Kolivas

Quoted 9 lines · Nick Piggin

Quoted 7 lines · Con Kolivas

Quoted 4 lines · Nick Piggin

prefetch_get_page is doing funny things with zones and nodes / zonelists (eg. 'We don't prefetch into DMA' meaning something like 'this only works
on i386 and x86-64').

Quoted 9 lines

Quoted 5 lines

Quoted 3 lines

Hrm? It's just a generic thing to do; I'm not sure I follow why it's i386 and x86-64 only. Every architecture has ZONE_NORMAL so it will prefetch there.

I don't think every architecture has ZONE_NORMAL.

!ZONE_DMA they all have, no?

Don't think so. IIRC ppc64 has only ZONE_DMA although may have picked up DMA32 now (/me boots the G5). IA64 I think have 4GB ZONE_DMA so smaller systems won't have any other zones.

On small memory systems, ZONE_DMA will be a significant portion of memory too (but maybe you're not targetting them either).

Quoted 22 lines · Nick Piggin

Quoted 20 lines · Con Kolivas

Quoted 9 lines · Nick Piggin

Quoted 7 lines · Con Kolivas

Quoted 4 lines · Nick Piggin

prefetch_get_page is doing funny things with zones and nodes / zonelists (eg. 'We don't prefetch into DMA' meaning something like 'this only works
on i386 and x86-64').

Quoted 5 lines

Quoted 3 lines

Hrm? It's just a generic thing to do; I'm not sure I follow why it's i386 and x86-64 only. Every architecture has ZONE_NORMAL so it will prefetch there.

I don't think every architecture has ZONE_NORMAL.

!ZONE_DMA they all have, no?

Quoted 6 lines

Don't think so. IIRC ppc64 has only ZONE_DMA although may have picked up DMA32 now (/me boots the G5). IA64 I think have 4GB ZONE_DMA so smaller systems won't have any other zones.

On small memory systems, ZONE_DMA will be a significant portion of memory too (but maybe you're not targetting them either).

embedded 32-bit PPC's have all their memory in DMA:

Quoted 4 lines

It introduces global cacheline bouncing in pagecache allocation and removal and page reclaim paths, also low watermark failure is quite common in normal operation, so that is another global cacheline write in page allocation path.

None of these issues is going to remotely the target audience. If the issue is how scalable such a change can be then I cannot advocate making the code smart and complex enough to be numa and cpuset aware.. but then that's never going to be the target audience. It affects a particular class of user which happens to be quite a large population not affected by complex memory hardware.

Con, responding to Nick:

Quoted 11 lines

Quoted 4 lines

It introduces global cacheline bouncing in pagecache allocation and removal and page reclaim paths, also low watermark failure is quite common in normal operation, so that is another global cacheline write in page allocation path.

None of these issues is going to remotely the target audience. If the issue is how scalable such a change can be then I cannot advocate making the code smart and complex enough to be numa and cpuset aware.. but then that's never going to be the target audience. It affects a particular class of user which happens to be quite a large population not affected by complex memory hardware.

How about only moving memory back to the Memory Node (zone) that it came from? And providing some call that Christoph Lameters migration code can call, to disable or fix this up, so you don't end up bringing back pages on their pre-migration nodes?

Just honoring the memory node placement should be sufficient. No need to wrap your head around cpusets.

If you don't do that, then consider disabling this thing entirely if CONFIG_NUMA is enabled. This swap prefetching sounds like it could be a loose canon ball in a NUMA box.

As for non-NUMA boxes, like my humble desktop PC, I would -love- to have Firefox come back up faster in the morning. I have a nightly cron jobs push everything out to swap, and it is slow going getting it back.

The day will come (it has already gotten there for some of my colleagues who are using a small Altix system for their desktop software) when we want this prefetching for NUMA boxes too.

Quoted 3 lines

If you don't do that, then consider disabling this thing entirely if CONFIG_NUMA is enabled. This swap prefetching sounds like it could be a loose canon ball in a NUMA box.

That's probably a less satisfactory option since NUMA isn't that rare with the light numa of commodity hardware.

Quoted 13 lines · Paul Jackson

Con, responding to Nick:

Quoted 11 lines

Quoted 4 lines

It introduces global cacheline bouncing in pagecache allocation and removal and page reclaim paths, also low watermark failure is quite common in normal operation, so that is another global cacheline write in page allocation path.

None of these issues is going to remotely the target audience. If the issue is how scalable such a change can be then I cannot advocate making the code smart and complex enough to be numa and cpuset aware.. but then that's never going to be the target audience. It affects a particular class of user which happens to be quite a large population not affected by complex memory hardware.

Quoted 4 lines

How about only moving memory back to the Memory Node (zone) that it came from? And providing some call that Christoph Lameters migration code can call, to disable or fix this up, so you don't end up bringing back pages on their pre-migration nodes?

Sounds good, and this is what I was hoping to be able to do; first I need to see the best time and place to get this information (and learn some more about the code).