appling preasure to icache and dcache
Subsystems (4)
---------- Forwarded Message ----------
Subject: Re: [PATCH][RFC] appling preasure to icache and dcache
Date: Tue, 3 Apr 2001 17:22:10 -0400
From: Ed Tomlinson <[email protected]>
To: [email protected]
Cc: l
Quoted 2 lines · Benjamin Redelings I
Hi, I'm glad somebody is working on this! VM-time seems like a pretty useful concept.
Think it might be useful for detecting trashing too. If vmtime is made to directly relate to the page allocation rate then you can do something like this. Let K be a number intially representing 25% of ram pages. Because vmtime is directly releated to allocation rates its meanful to subtract K from the current vmtime. For each swapped out page, record the current vmtime. Now if the recorded vmtime of the page you are swapping in is greater than vmtime-K increment A otherwise increment B. If A>B we are thrashing. We decay A and B via kswapd. We adjust K depending on the swapping rate. Thoughts?
Quoted 10 lines
I think you have a bug in your patch here:
+ if (base > pages) /* If the cache shrunk reset base, The
cache
+ base = pages; * growing applies preasure as does
expanding(quoted diff) +2
-0+ if (free > old) * free space - even if later shrinks */ + base -= (base>free-old) ? free-old : base;It looks like you unintentionally commented out two lines of code?
Geez. That will teach me to add comments _after_ testing the code... The patch as it stands, will not apply pressure as the caches expands. Good catch. Thanks.
Quoted 6 lines
I have been successfully running your patch. But I think it needs
benchmarks. At the very least, compile the kernel twice w/o and twice w/ your patch and see how it changes the times. I do not think I will have time to do it myself anytime soon unfortunately.
I have a 64Mb RAM machine, and the patch makes the system feel a little
bit slower when hitting the disk. BUt that is subjective...
Where I see a difference is with backups. With the patch applied they take about 2:20 or so, and use over 60K inodes/dentries, without the patch they take 2:35 (plus or minus 5 mins) and use over 190K inodes/dentries. On a box with lots of memory pressure (ie with 64M) I doubt that the calls to shrink the caches get triggered often from my code - expect that you are usually shrinking via do_try_to_free_pages. What might cause your subjective
difference may be the change in:
refill_inactive_scan(DEF_PRIORITY, delta);
You might want to try replacing this delta with 0 (in kswapd). If this
improves things for you I have to do a little rethinking...
Corrected patch follows:
---
diff -u -r --exclude-from=ex.txt linux.ac28/mm/page_alloc.c
linux/mm/page_alloc.c --- linux.ac28/mm/page_alloc.c Sun Apr 1 18:52:22
2001
+++ linux/mm/page_alloc.c Mon Apr 2 07:54:05 2001
@@ -138,11 +138,9 @@
/*
* We don't want to protect this variable from race conditions
- * since it's nothing important, but we do want to make sure
- * it never gets negative.
+ * since it's nothing important.
*/
- if (memory_pressure > NR_CPUS)
- memory_pressure--;
+ inactivate_pressure++;
}
#define MARK_USED(index, order, area) \
mm/swap.c +4 -1
@@ -47,10 +47,12 @@* many inactive pages we should have. * * In reclaim_page and __alloc_pages: memory_pressure++ -* In __free_pages_ok: memory_pressure-- +* In __free_pages_ok: inactivate_pressure++ +* In invalidate_pages_scan: inactivate_pressure++ * In recalculate_vm_stats the value is decayed (once a second) */ int memory_pressure; +int inactivate_pressure;/* We track the number of pages currently being asynchronously swapped out, so that we don't try to swap TOO many pages out at once */
@@ -287,6 +289,7 @@* memory_pressure. */ memory_pressure -= (memory_pressure >>INACTIVE_SHIFT ); + inactivate_pressure -= (inactivate_pressure >>INACTIVE_SHIFT ); }/*
mm/vmscan.c +87 -5
117 lines not on this page · raw message
include/linux/swap.h +1 -0
@@ -102,6 +102,7 @@/* linux/mm/swap.c */ extern int memory_pressure; +extern int inactivate_pressure;extern void age_page_up (struct page *);extern void age_page_up_nolock (struct page *);extern void age_page_down (struct page *);
---
Ed Tomlinson <[email protected]>
-------------------------------------------------------
--
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.eu.org/Linux-MM/
Quoted 4 lines · Ed Tomlinson
Quoted 2 lines · Benjamin Redelings I
Hi, I'm glad somebody is working on this! VM-time seems like a pretty useful concept.
Quoted 9 lines
Think it might be useful for detecting trashing too. If vmtime is made to directly relate to the page allocation rate then you can do something like this. Let K be a number intially representing 25% of ram pages. Because vmtime is directly releated to allocation rates its meanful to subtract K from the current vmtime. For each swapped out page, record the current vmtime. Now if the recorded vmtime of the page you are swapping in is greater than vmtime-K increment A otherwise increment B. If A>B we are thrashing. We decay A and B via kswapd. We adjust K depending on the swapping rate. Thoughts?
Hmmm, how exactly would this algorithm work ?
Quoted 1 line
From your description above, I can't quite see how it would
work (or why it would work).
regards,
Rik
--
Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose...
http://www.surriel.com/
http://www.conectiva.com/ http://distro.conectiva.com.br/
--
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.eu.org/Linux-MM/
Quoted 15 lines · Rik van Riel
Quoted 4 lines · Ed Tomlinson
Quoted 2 lines · Benjamin Redelings I
Hi, I'm glad somebody is working on this! VM-time seems like a pretty useful concept.
Quoted 9 lines
Think it might be useful for detecting trashing too. If vmtime is made to directly relate to the page allocation rate then you can do something like this. Let K be a number intially representing 25% of ram pages. Because vmtime is directly releated to allocation rates its meanful to subtract K from the current vmtime. For each swapped out page, record the current vmtime. Now if the recorded vmtime of the page you are swapping in is greater than vmtime-K increment A otherwise increment B. If A>B we are thrashing. We decay A and B via kswapd. We adjust K depending on the swapping rate. Thoughts?
Quoted 4 lines
Hmmm, how exactly would this algorithm work ?
From your description above, I can't quite see how it would work (or why it would work).
First remember the vmtime increments when ever we allocate a page. Second we record the vmtime for each page as its swapped out. If we are thrashing we are cycling through sets of pages. The swap out vmtime of most (if not all) of these pages will be greater than some K. So what I see the above doing is telling us we are swaping in stuff we reciently swapped out. If we are swapping normally this should not be a normal distribution. Another way to look at this would be to find a value of K such that |A-B| is small. If K is small and the swap rate is high we are thrashing. What is trashing is another question...
I am not sure this would catch _all_ cases but bet it would get a large percentage of them.
Ed
--
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.eu.org/Linux-MM/
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi. Just a few thoughts that I hope will be useful.
Quoted 5 lines · Ed Tomlinson
Quoted 4 lines · Rik van Riel
Quoted 3 lines · Ed Tomlinson
Quoted 2 lines · Benjamin Redelings I
Hi, I'm glad somebody is working on this! VM-time seems like a pretty useful concept.
The notion of VM time has been kicking around for about 10 years. I picked it up from my graduate advisor, and so it has worked its way into a number of research ideas. This approach to measuring VM time is an interesting one, and slightly different from the way in which I've approached it.
Quoted 9 lines
Quoted 9 lines
Quoted 9 lines
Think it might be useful for detecting trashing too. If vmtime is made to directly relate to the page allocation rate then you can do something like this. Let K be a number intially representing 25% of ram pages. Because vmtime is directly releated to allocation rates its meanful to subtract K from the current vmtime. For each swapped out page, record the current vmtime. Now if the recorded vmtime of the page you are swapping in is greater than vmtime-K increment A otherwise increment B. If A>B we are thrashing. We decay A and B via kswapd. We adjust K depending on the swapping rate. Thoughts?
A couple of thoughts:
1) Nit-pick: You mean "thrashing", not "trashing", right? Or is there a definition of "trashing" with which I'm not familiar?
2) There's a difference between detecting that the VM system is evicting pages and then using them shortly thereafter, and detecting thrashing. Your description above may detect the former case -- It's something that AIX did many years ago (or so I'm told by some IBM researchers), and it's a simplified case of what EELRU, an algorithm I was part of developing, detects. It's a useful case, because it likely indicates a loop-like reference pattern over slightly more memory than is available, forcing LRU to degenerate into FIFO.
However, it is not necessarily detecting thrashing. "Heavy paging" and "thrashing" aren't necessarily the same thing. Thrashing occurs when so much time is spent servicing page faults that the CPU rarely has any work to do (i.e. no ready processes to run.) It is easily possible to thrash without tripping the detection mechanism that you're describing.
3) Your detection mechanism seems as though it would detect something interesting. However, I don't understand the response that you describe. Decaying A and B seems fine, and an important part of accurate detection based on recent behavior. However, why adjust K? That doesn't seem to solve the problem. The process may still continue to reference pages evicted not long ago. Addressing this case reqires either a larger memory allocation (somehow or other) or a modification of the replacement policy (some non-LRU evictions). If you adjust K to be smaller, than you're just less likely to trip the detection mechanism. If you make K larger, it becomes more likely. You'll still have the same problem.
I hope these comments help. More likely than not, I've misunderstood what you're proposing. If so, please let me know what I've botched.
Scott Kaplan
[email protected]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE6yxZH8eFdWQtoOmgRAkggAJ4pY9eWIpl55yQteuYgD4eraCTk5wCgivNp etqUh9afUf2cZ7zA1dAVf30=
=YGhN
-----END PGP SIGNATURE-----
--
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.eu.org/Linux-MM/
Quoted 9 lines · On Wednesday 04 April 2001 08:40, [email protected] wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1Hi. Just a few thoughts that I hope will be useful.
Quoted 3 lines · Ed Tomlinson
Quoted 2 lines · Rik van Riel
Quoted 1 line · Ed Tomlinson
On Tuesday 03 April 2001 11:03, Benjamin Redelings I wrote:
Quoted 8 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Hi, I'm glad somebody is working on this! VM-time seems like a pretty useful concept.
The notion of VM time has been kicking around for about 10 years. I picked it up from my graduate advisor, and so it has worked its way into a number of research ideas. This approach to measuring VM time is an interesting one, and slightly different from the way in which I've approached it.
I am aware that vmtime has been around for a while - just not implemented in linux.
Quoted 10 lines
Quoted 9 lines
Quoted 9 lines
Quoted 9 lines
Think it might be useful for detecting trashing too. If vmtime is made to directly relate to the page allocation rate then you can do something like this. Let K be a number intially representing 25% of ram pages. Because vmtime is directly releated to allocation rates its meanful to subtract K from the current vmtime. For each swapped out page, record the current vmtime. Now if the recorded vmtime of the page you are swapping in is greater than vmtime-K increment A otherwise increment B. If A>B we are thrashing. We decay A and B via kswapd. We adjust K depending on the swapping rate. Thoughts?
Quoted 4 lines
A couple of thoughts:
1) Nit-pick: You mean "thrashing", not "trashing", right? Or is there a definition of "trashing" with which I'm not familiar?
Right - spelling is _not_ my forte.
Quoted 10 lines
2) There's a difference between detecting that the VM system is evicting pages and then using them shortly thereafter, and detecting thrashing. Your description above may detect the former case -- It's something that AIX did many years ago (or so I'm told by some IBM researchers), and it's a simplified case of what EELRU, an algorithm I was part of developing, detects. It's a useful case, because it likely indicates a loop-like reference pattern over slightly more memory than is available, forcing LRU to degenerate into FIFO.
Quoted 6 lines
However, it is not necessarily detecting thrashing. "Heavy paging" and "thrashing" aren't necessarily the same thing. Thrashing occurs when so much time is spent servicing page faults that the CPU rarely has any work to do (i.e. no ready processes to run.) It is easily possible to thrash without tripping the detection mechanism that you're describing.
I am very aware that heavy paging, which is ok _if_ you have the bandwidth, and thrashing are different.
Quoted 11 lines
3) Your detection mechanism seems as though it would detect something interesting. However, I don't understand the response that you describe. Decaying A and B seems fine, and an important part of accurate detection based on recent behavior. However, why adjust K? That doesn't seem to solve the problem. The process may still continue to reference pages evicted not long ago. Addressing this case reqires either a larger memory allocation (somehow or other) or a modification of the replacement policy (some non-LRU evictions). If you adjust K to be smaller, than you're just less likely to trip the detection mechanism. If you make K larger, it becomes more likely. You'll still have the same problem.
Wonder what gets detected if you adjust K such that abs(A-B) is small? if K is near the current vmtime you have a case where EELRU might help. as K approaches vmtime+physical pages you have thrashing? Think that, with some work, these sorts of metrics could be effective in detecting many cases of thrashing.
Quoted 2 lines
I hope these comments help. More likely than not, I've misunderstood what you're proposing. If so, please let me know what I've botched.
Comments like these always help (even the spelling <grin>).
Thanks
Ed Tomlinson <[email protected]>
--
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.eu.org/Linux-MM/
Quoted 2 lines · Ed Tomlinson
I am very aware that heavy paging, which is ok _if_ you have the bandwidth, and thrashing are different.
So can we conclude that for a simple "thrashing approximation" we should at least measure if we're loading the disk subsystem heavily ?
(heavy disk load -> more disk seeks -> self-perpetuating situation)
regards,
Rik
--
Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose...
http://www.surriel.com/
http://www.conectiva.com/ http://distro.conectiva.com.br/
--
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.eu.org/Linux-MM/