Quick question about hyper-threading (also some NUMA stuff)

DISCUSSION Timothy Miller 3 participants 14 messages Apr 14, 2003 – Apr 18, 2003

Subsystems (2)

Memory management MM core

lore

Share & tools

lore

Timothy Miller

author

2003-04-14 13:13 UTC #0 lore raw

From: Tony 'Nicoya' Mantler ([email protected])

Quoted 1 line

Perhaps the same effect could be obtained by preferentially scheduling

processes

Quoted 1 line

to execute on the "node" (a node being a single cpu in an SMP system, or

an HT

Quoted 4 lines

virtual CPU pair, or a NUMA node) that they were last running on.
I think the ideal semantics would probably be something along the lines

of:

Quoted 1 line

- a newly fork()ed thread executes on the same node as the creating

thread

Quoted 2 lines

- calling exec() sets a "feel free to shuffle me elsewhere" flag
- threads are otherwise only shuffled to other nodes when a certain load

ratio

Quoted 1 line

is exceeded (current-node:idle-node)

This sounds like the most sensible approach. I like considering the extremes of performance, but sometimes, the time for math required for some optimization can be worse than any benefit you get out of it. Your suggestion is simple. It increases the likelihood (10% better for little extra effort is better than 10% worse) of related processes being run on the same node, while not impacting the system's ability to balance load. This, as you say, is also very important for NUMA.

Does the NUMA support migrate pages to the node which is running a process? Or would processes jump nodes often enough to make that not worth the effort?

In order for page migration to be worth it, node affinity would have to be fairly strong. It's particularly important when a process maps pages which belong to another node. Is there any logic there to duplicate pages in cases where there is enough free memory for it? We'd have to tag the pages as duplicates so the VM could reclaim them.

Martin J. Bligh

2003-04-14 14:45 UTC #1 lore raw

Quoted 7 lines

This sounds like the most sensible approach. I like considering the extremes of performance, but sometimes, the time for math required for some optimization can be worse than any benefit you get out of it. Your suggestion is simple. It increases the likelihood (10% better for little extra effort is better than 10% worse) of related processes being run on the same node, while not impacting the system's ability to balance load. This, as you say, is also very important for NUMA.

See my earlier email - rebalance_node() does this, and it's very cheap, as we just SMP balance *within* the node - the cross node rebalancer is a separate tunable background process.

Quoted 3 lines

Does the NUMA support migrate pages to the node which is running a process? Or would processes jump nodes often enough to make that not worth the effort?

No, we don't do page migration as yet. Andi is playing with a homenode concept that makes pages allocate from a predefined "home node" always, instead of their current node. Last time I benchmarked that concept it sucked, but the advent of the per-cpu, per-zone hot/cold page cache, and the fact that he's using hardware with totally different NUMA characteristics may well change that conclusion.

We don't normally migrate stuff around much on the higher-ration NUMA machines. With AMD Hammer or whatever, that may change.

Quoted 5 lines

In order for page migration to be worth it, node affinity would have to be fairly strong. It's particularly important when a process maps pages which belong to another node. Is there any logic there to duplicate pages in cases where there is enough free memory for it? We'd have to tag the pages as duplicates so the VM could reclaim them.

Right - we're looking at read only text replication, first for the kernel (which ia64 has already), then for shared libs and program text. It's a good concept, provided you have plenty of RAM (which big NUMA boxes tend to). Probably needs hooking into the address space structure, and to be thrown away just like anything else that's unused under memory pressure from the per-node LRU lists. Though it'd be nice to mark them as particularly cheap to retrieve, and had a reference count (a node bitmap?) and to retrieve them from another node, not from disk.

Antonio Vargas

2003-04-14 15:07 UTC #2 lore raw

Quoted 32 lines · Martin J. Bligh

Quoted 7 lines
This sounds like the most sensible approach. I like considering the extremes of performance, but sometimes, the time for math required for some optimization can be worse than any benefit you get out of it. Your suggestion is simple. It increases the likelihood (10% better for little extra effort is better than 10% worse) of related processes being run on the same node, while not impacting the system's ability to balance load. This, as you say, is also very important for NUMA.
See my earlier email - rebalance_node() does this, and it's very cheap, as we just SMP balance *within* the node - the cross node rebalancer is a separate tunable background process.
Quoted 3 lines
Does the NUMA support migrate pages to the node which is running a process? Or would processes jump nodes often enough to make that not worth the effort?
No, we don't do page migration as yet. Andi is playing with a homenode concept that makes pages allocate from a predefined "home node" always, instead of their current node. Last time I benchmarked that concept it sucked, but the advent of the per-cpu, per-zone hot/cold page cache, and the fact that he's using hardware with totally different NUMA characteristics may well change that conclusion.
We don't normally migrate stuff around much on the higher-ration NUMA machines. With AMD Hammer or whatever, that may change.
Quoted 5 lines
In order for page migration to be worth it, node affinity would have to be fairly strong. It's particularly important when a process maps pages which belong to another node. Is there any logic there to duplicate pages in cases where there is enough free memory for it? We'd have to tag the pages as duplicates so the VM could reclaim them.

Quoted 8 lines

Right - we're looking at read only text replication, first for the kernel (which ia64 has already), then for shared libs and program text. It's a good concept, provided you have plenty of RAM (which big NUMA boxes tend to). Probably needs hooking into the address space structure, and to be thrown away just like anything else that's unused under memory pressure from the per-node LRU lists. Though it'd be nice to mark them as particularly cheap to retrieve, and had a reference count (a node bitmap?) and to retrieve them from another node, not from disk.

Perhaps it would be good to un-COW pages:

1. fork process
2. if current node is not loaded, continue as usual
3. if current node is loaded:
3a. pick unloaded node
4b. don't do COW for data pages, but simply copy them to node-local memory

This way, read-write sharings would be replicated for each node.

Also, keeping an per-node active-page-list and then forcefully copying the page to a node-local page-frame when accesing a page which is active on another node could be good.

Hmm, the un-COW system could be implemented in terms of the second one, isn't it?

Greets, Antonio.

Martin J. Bligh

2003-04-14 15:28 UTC #3 lore raw

Quoted 9 lines

Perhaps it would be good to un-COW pages:
1. fork process
2. if current node is not loaded, continue as usual
3. if current node is loaded:
3a. pick unloaded node
4b. don't do COW for data pages, but simply copy them to node-local memory
This way, read-write sharings would be replicated for each node.

Sharing read-write stuff is a total nightmare - you have to deal with all the sync stuff, and invalidation. In real-life scenarios, I really doubt the complexity is worth it - read-only is quite complex enough, thanks ;-)

Theoretically, if you had some pages that were predominatly read-only, and very occasionally got written to, it *might* be worth it. But probably not ;-)

Quoted 3 lines

Also, keeping an per-node active-page-list and then forcefully copying the page to a node-local page-frame when accesing a page which is active on another node could be good.

Not sure what you mean by this. wrt the active-page list here's a per-node LRU already. Or you mean something on a per-address-space basis?

Yes, faulting the pages in lazily from another node as we touch them is probably the right thing to do. Giving secondary copies some LRU disadvantage (perhaps always keeping them on the inactive list, never the active), would be fun, but then you get into the whole "who is the primary owner, and what do we do when they ditch the page" complexity. The node bitmap I suggested earlier might help. But I'd rather keep it simple at first ;-)

Antonio Vargas

2003-04-14 15:35 UTC #4 lore raw

Quoted 8 lines · Martin J. Bligh

Quoted 8 lines
Perhaps it would be good to un-COW pages:
1. fork process
2. if current node is not loaded, continue as usual
3. if current node is loaded:
3a. pick unloaded node
4b. don't do COW for data pages, but simply copy them to node-local memory

Quoted 6 lines

Quoted 1 line
This way, read-write sharings would be replicated for each node.
Sharing read-write stuff is a total nightmare - you have to deal with all the sync stuff, and invalidation. In real-life scenarios, I really doubt the complexity is worth it - read-only is quite complex enough, thanks ;-)

I mean MAP_PRIVATE stuff, not MAP_SHARED.

Quoted 10 lines

Theoretically, if you had some pages that were predominatly read-only, and very occasionally got written to, it *might* be worth it. But probably not ;-)
Quoted 3 lines
Also, keeping an per-node active-page-list and then forcefully copying the page to a node-local page-frame when accesing a page which is active on another node could be good.
Not sure what you mean by this. wrt the active-page list here's a per-node LRU already. Or you mean something on a per-address-space basis?

Yes, I meant a per-node active LRU. I'd better get a closer look at what's already done ;)

Quoted 8 lines

Yes, faulting the pages in lazily from another node as we touch them is probably the right thing to do. Giving secondary copies some LRU disadvantage (perhaps always keeping them on the inactive list, never the active), would be fun, but then you get into the whole "who is the primary owner, and what do we do when they ditch the page" complexity. The node bitmap I suggested earlier might help. But I'd rather keep it simple at first ;-)
M.

Antonio.

Martin J. Bligh

2003-04-14 16:13 UTC #5 lore raw

Quoted 8 lines

Quoted 8 lines
Quoted 8 lines
Perhaps it would be good to un-COW pages:
1. fork process
2. if current node is not loaded, continue as usual
3. if current node is loaded:
3a. pick unloaded node
4b. don't do COW for data pages, but simply copy them to node-local memory

Quoted 8 lines

Quoted 6 lines
Quoted 1 line
This way, read-write sharings would be replicated for each node.
Sharing read-write stuff is a total nightmare - you have to deal with all the sync stuff, and invalidation. In real-life scenarios, I really doubt the complexity is worth it - read-only is quite complex enough, thanks ;-)
I mean MAP_PRIVATE stuff, not MAP_SHARED.

OK, unless I misunderstand you, I think that happens naturally for that kind of thing - when we do the COW split, we'll get a node-local page by default (unless the local node is out of memory).

Antonio Vargas

2003-04-14 16:20 UTC #6 lore raw

Quoted 15 lines · Martin J. Bligh

Quoted 15 lines
Quoted 14 lines
Quoted 9 lines
Perhaps it would be good to un-COW pages:
1. fork process
2. if current node is not loaded, continue as usual
3. if current node is loaded:
3a. pick unloaded node
4b. don't do COW for data pages, but simply copy them to node-local memory
This way, read-write sharings would be replicated for each node.
Sharing read-write stuff is a total nightmare - you have to deal with all the sync stuff, and invalidation. In real-life scenarios, I really doubt the complexity is worth it - read-only is quite complex enough, thanks ;-)

Quoted 7 lines

Quoted 1 line
I mean MAP_PRIVATE stuff, not MAP_SHARED.
OK, unless I misunderstand you, I think that happens naturally for that kind of thing - when we do the COW split, we'll get a node-local page by default (unless the local node is out of memory).
M.

�
IYes, it happens naturaly, but it's done when we try to write to it. What I meant was, at fork time, it we are forking to a different node, instead of COW-marking, do the COW-mark and the immediately do a sort-of for_each_page(touch_as_if_written(page)), so that nodes would not have to reference the memory from others.

I don't know if it's really usefull, and anyways I could not try to code it unless there is a sort of NUMA simulator for "normal" machines.

Greets, Antonio.

Martin J. Bligh

2003-04-14 16:29 UTC #7 lore raw

Quoted 9 lines

Quoted 3 lines
OK, unless I misunderstand you, I think that happens naturally for that kind of thing - when we do the COW split, we'll get a node-local page by default (unless the local node is out of memory).
Yes, it happens naturaly, but it's done when we try to write to it. What I meant was, at fork time, it we are forking to a different node, instead of COW-marking, do the COW-mark and the immediately do a sort-of for_each_page(touch_as_if_written(page)), so that nodes would not have to reference the memory from others.

Ah, you probably don't want to do that ... it's very expensive. Moreover, if you exec 2ns later, all the effort will be wasted ... and it's very hard to deterministically predict whether you'll exec or not (stupid UNIX semantics). Doing it lazily is probably best, and as to "nodes would not have to reference the memory from others" - you're still doing that, you're just batching it on the front end.

Quoted 2 lines

I don't know if it's really usefull, and anyways I could not try to code it unless there is a sort of NUMA simulator for "normal" machines.

There isn't, but writing one would be very useful (and fairly simple) if you have a 2x machine or something that you could use. I've thought about writing this several times ... just haven't got round to it.

Antonio Vargas

2003-04-14 16:51 UTC #8 lore raw

Quoted 10 lines · Martin J. Bligh

Quoted 9 lines
Quoted 3 lines
OK, unless I misunderstand you, I think that happens naturally for that kind of thing - when we do the COW split, we'll get a node-local page by default (unless the local node is out of memory).
Yes, it happens naturaly, but it's done when we try to write to it. What I meant was, at fork time, it we are forking to a different node, instead of COW-marking, do the COW-mark and the immediately do a sort-of for_each_page(touch_as_if_written(page)), so that nodes would not have to reference the memory from others.

Quoted 6 lines

Ah, you probably don't want to do that ... it's very expensive. Moreover, if you exec 2ns later, all the effort will be wasted ... and it's very hard to deterministically predict whether you'll exec or not (stupid UNIX semantics). Doing it lazily is probably best, and as to "nodes would not have to reference the memory from others" - you're still doing that, you're just batching it on the front end.

True... What about a vma-level COW-ahead just like we have a file-level read-ahead, then? I mean batching the COW at unCOW-because-of-write time.

btw, COW-ahead sound really silly :)

Quoted 8 lines

Quoted 2 lines
I don't know if it's really usefull, and anyways I could not try to code it unless there is a sort of NUMA simulator for "normal" machines.
There isn't, but writing one would be very useful (and fairly simple) if you have a 2x machine or something that you could use. I've thought about writing this several times ... just haven't got round to it.
M.

Not possible for me since I've got no SMP. But posting a quick note about your proposed "fake-NUMA-on-SMP.patch" would be good only if to have an offsite (offbrain also? ;) backup of your ideas :)

Martin J. Bligh

2003-04-14 17:14 UTC #9 lore raw

Quoted 9 lines

Quoted 6 lines
Ah, you probably don't want to do that ... it's very expensive. Moreover, if you exec 2ns later, all the effort will be wasted ... and it's very hard to deterministically predict whether you'll exec or not (stupid UNIX semantics). Doing it lazily is probably best, and as to "nodes would not have to reference the memory from others" - you're still doing that, you're just batching it on the front end.
True... What about a vma-level COW-ahead just like we have a file-level read-ahead, then? I mean batching the COW at unCOW-because-of-write time.

That'd be interesting ... and you can test that on a UP box, is not just NUMA. Depends on the workload quite heavily, I suspect.

Quoted 1 line

btw, COW-ahead sound really silly :)

Yeah. So be sure to call it that if it works out ... we need more things like that ;-) Moooooo.

Quoted 3 lines

Not possible for me since I've got no SMP. But posting a quick note about your proposed "fake-NUMA-on-SMP.patch" would be good only if to have an offsite (offbrain also? ;) backup of your ideas :)

Oh, well basically you just need to split memory in half, and assign one cpu to each "node" for each cpu_to_node thingy. Would be easy to just do it as static #defines for sizes at first (most of the work in supporting a new NUMA arch is just parsing the machinet tables). Set MAX_NUMNODES to > 1, make sure you create a pgdat for each "node", and frig with build_zonelists and free_area_init_core a bit.

Antonio Vargas

2003-04-14 18:16 UTC #10 lore raw

cow-ahead N pages for fault clustering

Quoted 10 lines · Martin J. Bligh

Quoted 9 lines
Quoted 6 lines
Ah, you probably don't want to do that ... it's very expensive. Moreover, if you exec 2ns later, all the effort will be wasted ... and it's very hard to deterministically predict whether you'll exec or not (stupid UNIX semantics). Doing it lazily is probably best, and as to "nodes would not have to reference the memory from others" - you're still doing that, you're just batching it on the front end.
True... What about a vma-level COW-ahead just like we have a file-level read-ahead, then? I mean batching the COW at unCOW-because-of-write time.

Quoted 7 lines

That'd be interesting ... and you can test that on a UP box, is not just NUMA. Depends on the workload quite heavily, I suspect.
Quoted 1 line
btw, COW-ahead sound really silly :)
Yeah. So be sure to call it that if it works out ... we need more things like that ;-) Moooooo.

What about the attached one? I'm compiling it right now to test in UML :)

[ snip fake-NUMA-on-SMP discussion ]

Greets, Antonio.

 mm/memory.c |   32 ++++++++++++++++++++++++++++----
 1 files changed, 28 insertions(+), 4 deletions(-)

mm/memory.c renamed from mm/memory.c~cow-ahead +28 -4

diff -puN mm/memory.c~cow-ahead mm/memory.c
@@ -1452,7 +1452,7 @@ static int do_file_page(struct mm_struct
  */
 static inline int handle_pte_fault(struct mm_struct *mm,
 	struct vm_area_struct * vma, unsigned long address,
-	int write_access, pte_t *pte, pmd_t *pmd)
+	int write_access, pte_t *pte, pmd_t *pmd, int *cowahead)
 {
 	pte_t entry;

@@ -1471,8 +1471,11 @@ static inline int handle_pte_fault(struc
 	}
 
 	if (write_access) {
-		if (!pte_write(entry))
+		if (!pte_write(entry)) {
+			if(!cowahead)
+				*cowahead = 1;
 			return do_wp_page(mm, vma, address, pte, pmd, entry);
+		}
 
 		entry = pte_mkdirty(entry);
 	}

@@ -1492,6 +1495,17 @@ int handle_mm_fault(struct mm_struct *mm
 	pgd_t *pgd;
 	pmd_t *pmd;
 
+	int cowahead, i;
+	int retval, x;
+
+	/*
+	 * Implement cow-ahead: copy-on-write several
+	 * pages when we fault one of them
+	 */
+
+	i = cowahead = 0;
+
+do_cowahead:
 	__set_current_state(TASK_RUNNING);
 	pgd = pgd_offset(mm, address);

@@ -1509,8 +1523,18 @@ int handle_mm_fault(struct mm_struct *mm
 
 	if (pmd) {
 		pte_t * pte = pte_alloc_map(mm, pmd, address);
-		if (pte)
-			return handle_pte_fault(mm, vma, address, write_access, pte, pmd);
+		if (!pte) break;
+
+		x = handle_pte_fault(mm, vma, address, write_access, pte, pmd, cowahead);
+		if(!i) retval = x;
+
+		i++;
+		address += PAGE_SIZE;
+
+		if(!cowahead || i >= 0 || address >= vma->vm_end)
+			return retval;
+
+		goto do_cowahead;
 	}
 	spin_unlock(&mm->page_table_lock);
 	return VM_FAULT_OOM;

Antonio Vargas

2003-04-14 18:25 UTC #11 lore raw

Re: cow-ahead N pages for fault clustering

Quoted 14 lines · Antonio Vargas

Quoted 13 lines · Martin J. Bligh
Quoted 9 lines
Quoted 6 lines
Ah, you probably don't want to do that ... it's very expensive. Moreover, if you exec 2ns later, all the effort will be wasted ... and it's very hard to deterministically predict whether you'll exec or not (stupid UNIX semantics). Doing it lazily is probably best, and as to "nodes would not have to reference the memory from others" - you're still doing that, you're just batching it on the front end.
True... What about a vma-level COW-ahead just like we have a file-level read-ahead, then? I mean batching the COW at unCOW-because-of-write time.
That'd be interesting ... and you can test that on a UP box, is not just NUMA. Depends on the workload quite heavily, I suspect.

Quoted 9 lines

Quoted 4 lines
Quoted 1 line
btw, COW-ahead sound really silly :)
Yeah. So be sure to call it that if it works out ... we need more things like that ;-) Moooooo.
What about the attached one? I'm compiling it right now to test in UML :)
[ snip fake-NUMA-on-SMP discussion ]

OK, too quick for me... this next one applies, compiles and boots on 2.5.66 + uml. Now I wonder how can I test if this is useful... ideas?

Greets, Antonio.

 mm/memory.c |   34 +++++++++++++++++++++++++++++-----
 1 files changed, 29 insertions(+), 5 deletions(-)

mm/memory.c renamed from mm/memory.c~cow-ahead +29 -5

diff -puN mm/memory.c~cow-ahead mm/memory.c
@@ -1452,7 +1452,7 @@ static int do_file_page(struct mm_struct
  */
 static inline int handle_pte_fault(struct mm_struct *mm,
 	struct vm_area_struct * vma, unsigned long address,
-	int write_access, pte_t *pte, pmd_t *pmd)
+	int write_access, pte_t *pte, pmd_t *pmd, int *cowahead)
 {
 	pte_t entry;

@@ -1471,8 +1471,11 @@ static inline int handle_pte_fault(struc
 	}
 
 	if (write_access) {
-		if (!pte_write(entry))
+		if (!pte_write(entry)) {
+			if(!*cowahead)
+				*cowahead = 1;
 			return do_wp_page(mm, vma, address, pte, pmd, entry);
+		}
 
 		entry = pte_mkdirty(entry);
 	}

@@ -1492,6 +1495,17 @@ int handle_mm_fault(struct mm_struct *mm
 	pgd_t *pgd;
 	pmd_t *pmd;
 
+	int cowahead, i;
+	int retval, x;
+
+	/*
+	 * Implement cow-ahead: copy-on-write several
+	 * pages when we fault one of them
+	 */
+
+	i = cowahead = 0;
+
+do_cowahead:
 	__set_current_state(TASK_RUNNING);
 	pgd = pgd_offset(mm, address);

@@ -1507,10 +1521,20 @@ int handle_mm_fault(struct mm_struct *mm
 	spin_lock(&mm->page_table_lock);
 	pmd = pmd_alloc(mm, pgd, address);
 
-	if (pmd) {
+	while (pmd) {
 		pte_t * pte = pte_alloc_map(mm, pmd, address);
-		if (pte)
-			return handle_pte_fault(mm, vma, address, write_access, pte, pmd);
+		if (!pte) break;
+
+		x = handle_pte_fault(mm, vma, address, write_access, pte, pmd, &cowahead);
+		if(!i) retval = x;
+
+		i++;
+		address += PAGE_SIZE;
+
+		if(!cowahead || i >= 0 || address >= vma->vm_end)
+			return retval;
+
+		goto do_cowahead;
 	}
 	spin_unlock(&mm->page_table_lock);
 	return VM_FAULT_OOM;

Martin J. Bligh

2003-04-15 05:37 UTC #12 lore raw

Re: cow-ahead N pages for fault clustering

Quoted 20 lines

Quoted 20 lines
Quoted 19 lines
Quoted 11 lines
Quoted 7 lines
Ah, you probably don't want to do that ... it's very expensive. Moreover, if you exec 2ns later, all the effort will be wasted ... and it's very hard to deterministically predict whether you'll exec or not (stupid UNIX semantics). Doing it lazily is probably best, and as to "nodes would not have to reference the memory from others" - you're still doing that, you're just batching it on the front end.
True... What about a vma-level COW-ahead just like we have a file-level read-ahead, then? I mean batching the COW at unCOW-because-of-write time.
That'd be interesting ... and you can test that on a UP box, is not just NUMA. Depends on the workload quite heavily, I suspect.
Quoted 1 line
btw, COW-ahead sound really silly :)
Yeah. So be sure to call it that if it works out ... we need more things like that ;-) Moooooo.

Quoted 7 lines

Quoted 4 lines
What about the attached one? I'm compiling it right now to test in UML :)
[ snip fake-NUMA-on-SMP discussion ]
OK, too quick for me... this next one applies, compiles and boots on 2.5.66 + uml. Now I wonder how can I test if this is useful... ideas?

Well, benchmark it ;-) My favourite trick is to just "/usr/bin/time make bzImage" on some fixed kernel version & config, but aim7 / aim9 is pretty easy to set up too, and might be interesting.

Antonio Vargas

2003-04-18 17:11 UTC #13 lore raw

Re: cow-ahead N pages for fault clustering

Quoted 25 lines · Martin J. Bligh

Quoted 25 lines
Quoted 24 lines
Quoted 12 lines
Quoted 11 lines
Quoted 7 lines
Ah, you probably don't want to do that ... it's very expensive. Moreover, if you exec 2ns later, all the effort will be wasted ... and it's very hard to deterministically predict whether you'll exec or not (stupid UNIX semantics). Doing it lazily is probably best, and as to "nodes would not have to reference the memory from others" - you're still doing that, you're just batching it on the front end.
True... What about a vma-level COW-ahead just like we have a file-level read-ahead, then? I mean batching the COW at unCOW-because-of-write time.
Quoted 7 lines
That'd be interesting ... and you can test that on a UP box, is not just NUMA. Depends on the workload quite heavily, I suspect.
Quoted 1 line
btw, COW-ahead sound really silly :)
Yeah. So be sure to call it that if it works out ... we need more things like that ;-) Moooooo.
What about the attached one? I'm compiling it right now to test in UML :)
[ snip fake-NUMA-on-SMP discussion ]

Quoted 8 lines

Quoted 2 lines
OK, too quick for me... this next one applies, compiles and boots on 2.5.66 + uml. Now I wonder how can I test if this is useful... ideas?
Well, benchmark it ;-) My favourite trick is to just "/usr/bin/time make bzImage" on some fixed kernel version & config, but aim7 / aim9 is pretty easy to set up too, and might be interesting.
M.

I've benchmarked my patch with a 2-pages-per-fault loop:

make allnoconfig
date >>aaa
make bzImage
date >>aaa

and then checked manually the time difference

Took the same time both on vanilla 2.5.66 and my 2.5.66+cowahead.

Perhaps it's better for other workloads...

ps. my posted patch had a little bug: it did the cow loop only 1 time,
so it only cow'ed 1 page... be sure to change the end test if you want to benchmark it futher.