mm: MADV_WILLNEED implementation for anonymous memory

Subject: mm: MADV_WILLNEED implementation for anonymous memory

Implement MADV_WILLNEED for anonymous pages by walking the page tables and starting asynchonous swap cache reads for all encountered swap pages.

Doing so required a modification to the page table walking library functions. Previously ->pte_entry() could be called while holding a kmap_atomic, to overcome this problem the pte walker is changed to copy batches of the pmd and iterate them.

mm/pagewalk.c +10 -2

+/*
+ * Much of the complication here is to work around CONFIG_HIGHPTE which needs
+ * to kmap the pmd. So copy batches of ptes from the pmd and iterate over
+ * those.
+ */
+#define WALK_BATCH_SIZE	32
+
 static int walk_pte_range(pmd_t *pmd, unsigned long addr, unsigned long end,
 			  const struct mm_walk *walk, void *private)
 {
 	pte_t *pte;
+	pte_t ptes[WALK_BATCH_SIZE];
+	unsigned long start;
+	unsigned int i;
 	int err = 0;
 
-	pte = pte_offset_map(pmd, addr);
 	do {
-		err = walk->pte_entry(pte, addr, addr + PAGE_SIZE, private);

Implement MADV_WILLNEED for anonymous pages by walking the page tables and starting asynchonous swap cache reads for all encountered swap pages.

Quoted 2 lines · On Wed, 30 Jan 2008 18:28:59 +0100 Peter Zijlstra <[email protected]>…

Implement MADV_WILLNEED for anonymous pages by walking the page tables and starting asynchonous swap cache reads for all encountered swap pages.

Why cannot this use (a perhaps suitably-modified) make_pages_present()?

Quoted 6 lines · Andrew Morton

Quoted 2 lines · On Wed, 30 Jan 2008 18:28:59 +0100 Peter Zijlstra <[email protected]>…

Implement MADV_WILLNEED for anonymous pages by walking the page tables and starting asynchonous swap cache reads for all encountered swap pages.

Quoted 1 line

Why cannot this use (a perhaps suitably-modified) make_pages_present()?

Because make_pages_present() relies on page faults to bring data in and will thus wait for all data to be present before returning.

This solution is async; it will just issue a read for the requested pages and moves on.

Implementation-wise: make_pages_present() _can_ be converted to do this. But it's a lot of patching, and the result will be a cleaner, faster and smaller core MM. Whereas your approach is easy, but adds more code and leaves the old stuff slow-and-dirty.

Guess which approach is preferred? ;)

Quoted 6 lines · Andrew Morton

Implementation-wise: make_pages_present() _can_ be converted to do this. But it's a lot of patching, and the result will be a cleaner, faster and smaller core MM. Whereas your approach is easy, but adds more code and leaves the old stuff slow-and-dirty.

Guess which approach is preferred? ;)

Ok, I'll look at using make_pages_present().

Quoted 8 lines · On Thu, 31 Jan 2008 10:35:18 +0100 Peter Zijlstra <[email protected]>…

Quoted 5 lines · Andrew Morton

Implementation-wise: make_pages_present() _can_ be converted to do this. But it's a lot of patching, and the result will be a cleaner, faster and smaller core MM. Whereas your approach is easy, but adds more code and leaves the old stuff slow-and-dirty.

Quoted 3 lines

Quoted 1 line

Guess which approach is preferred? ;)

Ok, I'll look at using make_pages_present().

Am still curious to know what inspired this change. What are the use cases? Performance testing results, etc?

Quoted 10 lines · Andrew Morton

Quoted 8 lines · On Thu, 31 Jan 2008 10:35:18 +0100 Peter Zijlstra <[email protected]>…

Quoted 5 lines · Andrew Morton

Implementation-wise: make_pages_present() _can_ be converted to do this. But it's a lot of patching, and the result will be a cleaner, faster and smaller core MM. Whereas your approach is easy, but adds more code and leaves the old stuff slow-and-dirty.

Quoted 6 lines

Quoted 3 lines

Quoted 1 line

Guess which approach is preferred? ;)

Ok, I'll look at using make_pages_present().

Am still curious to know what inspired this change. What are the use cases? Performance testing results, etc?

Ah, that is Lennarts Pulse Audio thing, he has samples in memory which might not have been used for a while, and he wants to be able to pre-fetch those when he suspects they might need to be played. So that once the audio thread comes along and stuffs them down /dev/dsp its all nice in memory.

Since its all soft real-time at best he feels its better to do a best effort at not hitting swap than it is to strain the system with mlock usage.

Quoted 25 lines · On Thu, 31 Jan 2008 10:53:26 +0100 Peter Zijlstra <[email protected]>…

Quoted 10 lines · Andrew Morton

Quoted 8 lines · On Thu, 31 Jan 2008 10:35:18 +0100 Peter Zijlstra <[email protected]>…

Quoted 5 lines · Andrew Morton

Implementation-wise: make_pages_present() _can_ be converted to do this. But it's a lot of patching, and the result will be a cleaner, faster and smaller core MM. Whereas your approach is easy, but adds more code and leaves the old stuff slow-and-dirty.

Quoted 6 lines

Quoted 3 lines

Quoted 1 line

Guess which approach is preferred? ;)

Ok, I'll look at using make_pages_present().

Am still curious to know what inspired this change. What are the use cases? Performance testing results, etc?

Ah, that is Lennarts Pulse Audio thing, he has samples in memory which might not have been used for a while, and he wants to be able to pre-fetch those when he suspects they might need to be played. So that once the audio thread comes along and stuffs them down /dev/dsp its all nice in memory.

Quoted 3 lines

Since its all soft real-time at best he feels its better to do a best effort at not hitting swap than it is to strain the system with mlock usage.

hrm. Does he know about pthread_create()?

Quoted 31 lines · Andrew Morton

Quoted 28 lines · On Thu, 31 Jan 2008 10:53:26 +0100 Peter Zijlstra <[email protected]>…

Quoted 10 lines · Andrew Morton

Quoted 8 lines · On Thu, 31 Jan 2008 10:35:18 +0100 Peter Zijlstra <[email protected]>…

Quoted 5 lines · Andrew Morton

Implementation-wise: make_pages_present() _can_ be converted to do this. But it's a lot of patching, and the result will be a cleaner, faster and smaller core MM. Whereas your approach is easy, but adds more code and leaves the old stuff slow-and-dirty.

Quoted 6 lines

Quoted 3 lines

Quoted 1 line

Guess which approach is preferred? ;)

Ok, I'll look at using make_pages_present().

Am still curious to know what inspired this change. What are the use cases? Performance testing results, etc?

Ah, that is Lennarts Pulse Audio thing, he has samples in memory which might not have been used for a while, and he wants to be able to pre-fetch those when he suspects they might need to be played. So that once the audio thread comes along and stuffs them down /dev/dsp its all nice in memory.

Since its all soft real-time at best he feels its better to do a best effort at not hitting swap than it is to strain the system with mlock usage.

Quoted 1 line

hrm. Does he know about pthread_create()?

I'm very sure he does. So you're suggesting to just create a thread and touch that memory and be done with it?

Lennart?

Ah, that is Lennarts Pulse Audio thing, he has samples in memory which might not have been used for a while, and he wants to be able to pre-fetch those when he suspects they might need to be played. So that once the audio thread comes along and stuffs them down /dev/dsp its all nice in memory.

Quoted 6 lines · Peter Zijlstra

Ah, that is Lennarts Pulse Audio thing, he has samples in memory which might not have been used for a while, and he wants to be able to pre-fetch those when he suspects they might need to be played. So that once the audio thread comes along and stuffs them down /dev/dsp its all nice in memory.

The real problem that seems to make swapping so slow is that the data tends to be badly fragmented on the swap partition. I suspect if that problem was attached the need for such prefetching would be far less because swap in would be much faster.

Yeah, the 2.5 switch to physical scanning killed us there.

I still don't know why my allocate-swapspace-according-to-virtual-address change didn't help. Much. Marcelo played with that a bit too.

Quoted 5 lines

Yeah, the 2.5 switch to physical scanning killed us there.

I still don't know why my allocate-swapspace-according-to-virtual-address change didn't help. Much. Marcelo played with that a bit too.

I've been thinking about just always doing swap on > page clusters. Any reason swapping couldn't be done on e.g. 1MB chunks?

Quoted 6 lines · On Thu, 31 Jan 2008 12:06:10 +0100 Andi Kleen <[email protected]> wrote:

Quoted 5 lines

Yeah, the 2.5 switch to physical scanning killed us there.

I still don't know why my allocate-swapspace-according-to-virtual-address change didn't help. Much. Marcelo played with that a bit too.

Quoted 2 lines

I've been thinking about just always doing swap on > page clusters. Any reason swapping couldn't be done on e.g. 1MB chunks?

Don't malloc() and free() hopelessly fragment memory over time, ensuring that little related data can be found inside each 1MB chunk if the process is large enough? (say, firefox)

Quoted 4 lines · Rik van Riel

Don't malloc() and free() hopelessly fragment memory over time, ensuring that little related data can be found inside each 1MB chunk if the process is large enough? (say, firefox)

Even if they do (I don't know if it's true or not) it does not really matter because on modern hard disks/systems it does not cost less to transfer 1MB versus 4K. The actual threshold seems to be rising in fact.

The only drawback is that the swap might be full sooner, but I would actually consider this a feature because it would likely end many prolonged oom death dances much sooner.