diff for duplicates of <20101122020145.GB10126@localhost> diff --git a/a/1.txt b/N1/1.txt index e3377f9..bab7308 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -217,3 +217,10 @@ You get the dynamics right :) Thanks, Fengguang + +-- +To unsubscribe, send a message with 'unsubscribe linux-mm' in +the body to majordomo@kvack.org. For more info on Linux MM, +see: http://www.linux-mm.org/ . +Fight unfair telecom policy in Canada: sign http://dissolvethecrtc.ca/ +Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> diff --git a/a/content_digest b/N1/content_digest index 79181dd..02d8d80 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -239,6 +239,13 @@ "> Thanks for the great work.\n" "\n" "Thanks,\n" - Fengguang + "Fengguang\n" + "\n" + "--\n" + "To unsubscribe, send a message with 'unsubscribe linux-mm' in\n" + "the body to majordomo@kvack.org. For more info on Linux MM,\n" + "see: http://www.linux-mm.org/ .\n" + "Fight unfair telecom policy in Canada: sign http://dissolvethecrtc.ca/\n" + "Don't email: <a href=mailto:\"dont@kvack.org\"> email@kvack.org </a>" -a59bd5a0eea53e5a3035074f6c510c027e575b0b27a96ec444b9d98c7c78e11a +ca4fa55e88eb0678db27189c08037f45f8d75ec38152dc96d1f60eff5b29d350
diff --git a/a/1.txt b/N2/1.txt index e3377f9..39dedc0 100644 --- a/a/1.txt +++ b/N2/1.txt @@ -32,28 +32,28 @@ optimal control theory. > > > > - concurrent writeback of multiple inodes (Dave Chinner) > > -> > If every thread doing writes and being throttled start foreground -> > writeback, it leads to N IO submitters from at least N different -> > inodes at the same time, end up with N different sets of IO being -> > issued with potentially zero locality to each other, resulting in -> > much lower elevator sort/merge efficiency and hence we seek the disk -> > all over the place to service the different sets of IO. -> > OTOH, if there is only one submission thread, it doesn't jump between -> > inodes in the same way when congestion clears - it keeps writing to -> > the same inode, resulting in large related chunks of sequential IOs -> > being issued to the disk. This is more efficient than the above -> > foreground writeback because the elevator works better and the disk -> > seeks less. +> > A If every thread doing writes and being throttled start foreground +> > A writeback, it leads to N IO submitters from at least N different +> > A inodes at the same time, end up with N different sets of IO being +> > A issued with potentially zero locality to each other, resulting in +> > A much lower elevator sort/merge efficiency and hence we seek the disk +> > A all over the place to service the different sets of IO. +> > A OTOH, if there is only one submission thread, it doesn't jump between +> > A inodes in the same way when congestion clears - it keeps writing to +> > A the same inode, resulting in large related chunks of sequential IOs +> > A being issued to the disk. This is more efficient than the above +> > A foreground writeback because the elevator works better and the disk +> > A seeks less. > > > > - IO size too small for fast arrays and too large for slow USB sticks > > -> > The write_chunk used by current balance_dirty_pages() cannot be -> > directly set to some large value (eg. 128MB) for better IO efficiency. -> > Because it could lead to more than 1 second user perceivable stalls. -> > Even the current 4MB write size may be too large for slow USB sticks. -> > The fact that balance_dirty_pages() starts IO on itself couples the -> > IO size to wait time, which makes it hard to do suitable IO size while -> > keeping the wait time under control. +> > A The write_chunk used by current balance_dirty_pages() cannot be +> > A directly set to some large value (eg. 128MB) for better IO efficiency. +> > A Because it could lead to more than 1 second user perceivable stalls. +> > A Even the current 4MB write size may be too large for slow USB sticks. +> > A The fact that balance_dirty_pages() starts IO on itself couples the +> > A IO size to wait time, which makes it hard to do suitable IO size while +> > A keeping the wait time under control. > > > > For the above two reasons, it's much better to shift IO to the flusher > > threads and let balance_dirty_pages() just wait for enough time or progress. @@ -63,13 +63,13 @@ optimal control theory. > > safeguard the dirty limit. However it's found to have two problems: > > > > - in large NUMA systems, the per-cpu counters may have big accounting -> > errors, leading to big throttle wait time and jitters. +> > A errors, leading to big throttle wait time and jitters. > > > > - NFS may kill large amount of unstable pages with one single COMMIT. -> > Because NFS server serves COMMIT with expensive fsync() IOs, it is -> > desirable to delay and reduce the number of COMMITs. So it's not -> > likely to optimize away such kind of bursty IO completions, and the -> > resulted large (and tiny) stall times in IO completion based throttling. +> > A Because NFS server serves COMMIT with expensive fsync() IOs, it is +> > A desirable to delay and reduce the number of COMMITs. So it's not +> > A likely to optimize away such kind of bursty IO completions, and the +> > A resulted large (and tiny) stall times in IO completion based throttling. > > > > So here is a pause time oriented approach, which tries to control the > > pause time in each balance_dirty_pages() invocations, by controlling @@ -77,7 +77,7 @@ optimal control theory. > > smooth and efficient dirty throttling: > > > > - avoid useless (eg. zero pause time) balance_dirty_pages() calls -> > - avoid too small pause time (less than 10ms, which burns CPU power) +> > - avoid too small pause time (less than A 10ms, which burns CPU power) > > - avoid too large pause time (more than 100ms, which hurts responsiveness) > > - avoid big fluctuations of pause times > > @@ -104,13 +104,13 @@ optimal control theory. > > > > after patch, the pause time remains stable around 32ms > > -> > cp-2687 [002] 1452.237012: balance_dirty_pages: weight=56% dirtied=128 pause=8 -> > cp-2687 [002] 1452.246157: balance_dirty_pages: weight=56% dirtied=128 pause=8 -> > cp-2687 [006] 1452.253043: balance_dirty_pages: weight=56% dirtied=128 pause=8 -> > cp-2687 [006] 1452.261899: balance_dirty_pages: weight=57% dirtied=128 pause=8 -> > cp-2687 [006] 1452.268939: balance_dirty_pages: weight=57% dirtied=128 pause=8 -> > cp-2687 [002] 1452.276932: balance_dirty_pages: weight=57% dirtied=128 pause=8 -> > cp-2687 [002] 1452.285889: balance_dirty_pages: weight=57% dirtied=128 pause=8 +> > cp-2687 A [002] A 1452.237012: balance_dirty_pages: weight=56% dirtied=128 pause=8 +> > cp-2687 A [002] A 1452.246157: balance_dirty_pages: weight=56% dirtied=128 pause=8 +> > cp-2687 A [006] A 1452.253043: balance_dirty_pages: weight=56% dirtied=128 pause=8 +> > cp-2687 A [006] A 1452.261899: balance_dirty_pages: weight=57% dirtied=128 pause=8 +> > cp-2687 A [006] A 1452.268939: balance_dirty_pages: weight=57% dirtied=128 pause=8 +> > cp-2687 A [002] A 1452.276932: balance_dirty_pages: weight=57% dirtied=128 pause=8 +> > cp-2687 A [002] A 1452.285889: balance_dirty_pages: weight=57% dirtied=128 pause=8 > > > > CONTROL SYSTEM > > ============== @@ -126,28 +126,28 @@ optimal control theory. > > because R << B in fig.1). > > > > Fig.1 before patch, a heavy dirtier and a light dirtier -> > R +> > A A A A A A A A A A A A A A A A A A A A A A A A R > > ----------------------------------------------+-o---------------------------*--| -> > L A B T -> > T: bdi_dirty_limit, as returned by bdi_dirty_limit() -> > L: T - T/8 +> > A A A A A A A A A A A A A A A A A A A A A A A L A A A A A A A A A A A A A A B A T +> > A T: bdi_dirty_limit, as returned by bdi_dirty_limit() +> > A L: T - T/8 > > -> > R: bdi_reclaimable + bdi_writeback +> > A R: bdi_reclaimable + bdi_writeback > > -> > A: task_dirty_limit for a heavy dirtier ~= R ~= L -> > B: task_dirty_limit for a light dirtier ~= T +> > A A: task_dirty_limit for a heavy dirtier ~= R ~= L +> > A B: task_dirty_limit for a light dirtier ~= T > > > > Since each process has its own dirty limit, we reuse A/B for the tasks as > > well as their dirty limits. > > > > If B is a newly started heavy dirtier, then it will slowly gain weight -> > and A will lose weight. The task_dirty_limit for A and B will be +> > and A will lose weight. A The task_dirty_limit for A and B will be > > approaching the center of region (L, T) and eventually stabilize there. > > > > Fig.2 before patch, two heavy dirtiers converging to the same threshold -> > R +> > A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A R > > ----------------------------------------------+--------------o-*---------------| -> > L A B T +> > A A A A A A A A A A A A A A A A A A A A A A A L A A A A A A A A B A A A A A A A T > > Seems good until now. > So, What's the problem if two heavy dirtiers have a same threshold? @@ -156,33 +156,33 @@ That's not a problem. It's the proper behavior to converge for two "dd"s. > > Fig.3 after patch, one heavy dirtier -> > | -> > throttle_bandwidth ~= bdi_bandwidth => o -> > | o -> > | o -> > | o -> > | o -> > | o -> > La| o +> > A A A A A A A A A A A A A A A A A A A A A A A A | +> > A A throttle_bandwidth ~= bdi_bandwidth A => A A o +> > A A A A A A A A A A A A A A A A A A A A A A A A | o +> > A A A A A A A A A A A A A A A A A A A A A A A A | A o +> > A A A A A A A A A A A A A A A A A A A A A A A A | A A o +> > A A A A A A A A A A A A A A A A A A A A A A A A | A A A o +> > A A A A A A A A A A A A A A A A A A A A A A A A | A A A A o +> > A A A A A A A A A A A A A A A A A A A A A A A La| A A A A A o > > ----------------------------------------------+-+-------------o----------------| -> > R A T -> > T: bdi_dirty_limit -> > A: task_dirty_limit = T - Wa * T/16 -> > La: task_throttle_thresh = A - A/16 +> > A A A A A A A A A A A A A A A A A A A A A A A A R A A A A A A A A A A A A A A A T +> > A T: bdi_dirty_limit +> > A A: task_dirty_limit A A A = T - Wa * T/16 +> > A La: task_throttle_thresh = A - A/16 > > -> > R: bdi_dirty_pages = bdi_reclaimable + bdi_writeback ~= La +> > A R: bdi_dirty_pages = bdi_reclaimable + bdi_writeback ~= La > > > > Now for IO-less balance_dirty_pages(), let's do it in a "bandwidth control" > > way. In fig.3, a soft dirty limit region (La, A) is introduced. When R enters > > this region, the task may be throttled for J jiffies on every N pages it dirtied. > > Let's call (N/J) the "throttle bandwidth". It is computed by the following formula: > > -> > throttle_bandwidth = bdi_bandwidth * (A - R) / (A - La) +> > A A A A throttle_bandwidth = bdi_bandwidth * (A - R) / (A - La) > > where -> > A = T - Wa * T/16 -> > La = A - A/16 +> > A A A A A = T - Wa * T/16 +> > A A A A La = A - A/16 > > where Wa is task weight for A. It's 0 for very light dirtier and 1 for -> > the one heavy dirtier (that consumes 100% bdi write bandwidth). The +> > the one heavy dirtier (that consumes 100% bdi write bandwidth). A The > > task weight will be updated independently by task_dirty_inc() at > > set_page_dirty() time. > @@ -217,3 +217,10 @@ You get the dynamics right :) Thanks, Fengguang + +-- +To unsubscribe, send a message with 'unsubscribe linux-mm' in +the body to majordomo@kvack.org. For more info on Linux MM, +see: http://www.linux-mm.org/ . +Fight unfair telecom policy in Canada: sign http://dissolvethecrtc.ca/ +Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> diff --git a/a/content_digest b/N2/content_digest index 79181dd..9b82745 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -55,28 +55,28 @@ "> >\n" "> > - concurrent writeback of multiple inodes (Dave Chinner)\n" "> >\n" - "> > \302\240If every thread doing writes and being throttled start foreground\n" - "> > \302\240writeback, it leads to N IO submitters from at least N different\n" - "> > \302\240inodes at the same time, end up with N different sets of IO being\n" - "> > \302\240issued with potentially zero locality to each other, resulting in\n" - "> > \302\240much lower elevator sort/merge efficiency and hence we seek the disk\n" - "> > \302\240all over the place to service the different sets of IO.\n" - "> > \302\240OTOH, if there is only one submission thread, it doesn't jump between\n" - "> > \302\240inodes in the same way when congestion clears - it keeps writing to\n" - "> > \302\240the same inode, resulting in large related chunks of sequential IOs\n" - "> > \302\240being issued to the disk. This is more efficient than the above\n" - "> > \302\240foreground writeback because the elevator works better and the disk\n" - "> > \302\240seeks less.\n" + "> > A If every thread doing writes and being throttled start foreground\n" + "> > A writeback, it leads to N IO submitters from at least N different\n" + "> > A inodes at the same time, end up with N different sets of IO being\n" + "> > A issued with potentially zero locality to each other, resulting in\n" + "> > A much lower elevator sort/merge efficiency and hence we seek the disk\n" + "> > A all over the place to service the different sets of IO.\n" + "> > A OTOH, if there is only one submission thread, it doesn't jump between\n" + "> > A inodes in the same way when congestion clears - it keeps writing to\n" + "> > A the same inode, resulting in large related chunks of sequential IOs\n" + "> > A being issued to the disk. This is more efficient than the above\n" + "> > A foreground writeback because the elevator works better and the disk\n" + "> > A seeks less.\n" "> >\n" "> > - IO size too small for fast arrays and too large for slow USB sticks\n" "> >\n" - "> > \302\240The write_chunk used by current balance_dirty_pages() cannot be\n" - "> > \302\240directly set to some large value (eg. 128MB) for better IO efficiency.\n" - "> > \302\240Because it could lead to more than 1 second user perceivable stalls.\n" - "> > \302\240Even the current 4MB write size may be too large for slow USB sticks.\n" - "> > \302\240The fact that balance_dirty_pages() starts IO on itself couples the\n" - "> > \302\240IO size to wait time, which makes it hard to do suitable IO size while\n" - "> > \302\240keeping the wait time under control.\n" + "> > A The write_chunk used by current balance_dirty_pages() cannot be\n" + "> > A directly set to some large value (eg. 128MB) for better IO efficiency.\n" + "> > A Because it could lead to more than 1 second user perceivable stalls.\n" + "> > A Even the current 4MB write size may be too large for slow USB sticks.\n" + "> > A The fact that balance_dirty_pages() starts IO on itself couples the\n" + "> > A IO size to wait time, which makes it hard to do suitable IO size while\n" + "> > A keeping the wait time under control.\n" "> >\n" "> > For the above two reasons, it's much better to shift IO to the flusher\n" "> > threads and let balance_dirty_pages() just wait for enough time or progress.\n" @@ -86,13 +86,13 @@ "> > safeguard the dirty limit. However it's found to have two problems:\n" "> >\n" "> > - in large NUMA systems, the per-cpu counters may have big accounting\n" - "> > \302\240errors, leading to big throttle wait time and jitters.\n" + "> > A errors, leading to big throttle wait time and jitters.\n" "> >\n" "> > - NFS may kill large amount of unstable pages with one single COMMIT.\n" - "> > \302\240Because NFS server serves COMMIT with expensive fsync() IOs, it is\n" - "> > \302\240desirable to delay and reduce the number of COMMITs. So it's not\n" - "> > \302\240likely to optimize away such kind of bursty IO completions, and the\n" - "> > \302\240resulted large (and tiny) stall times in IO completion based throttling.\n" + "> > A Because NFS server serves COMMIT with expensive fsync() IOs, it is\n" + "> > A desirable to delay and reduce the number of COMMITs. So it's not\n" + "> > A likely to optimize away such kind of bursty IO completions, and the\n" + "> > A resulted large (and tiny) stall times in IO completion based throttling.\n" "> >\n" "> > So here is a pause time oriented approach, which tries to control the\n" "> > pause time in each balance_dirty_pages() invocations, by controlling\n" @@ -100,7 +100,7 @@ "> > smooth and efficient dirty throttling:\n" "> >\n" "> > - avoid useless (eg. zero pause time) balance_dirty_pages() calls\n" - "> > - avoid too small pause time (less than \302\24010ms, which burns CPU power)\n" + "> > - avoid too small pause time (less than A 10ms, which burns CPU power)\n" "> > - avoid too large pause time (more than 100ms, which hurts responsiveness)\n" "> > - avoid big fluctuations of pause times\n" "> >\n" @@ -127,13 +127,13 @@ "> >\n" "> > after patch, the pause time remains stable around 32ms\n" "> >\n" - "> > cp-2687 \302\240[002] \302\2401452.237012: balance_dirty_pages: weight=56% dirtied=128 pause=8\n" - "> > cp-2687 \302\240[002] \302\2401452.246157: balance_dirty_pages: weight=56% dirtied=128 pause=8\n" - "> > cp-2687 \302\240[006] \302\2401452.253043: balance_dirty_pages: weight=56% dirtied=128 pause=8\n" - "> > cp-2687 \302\240[006] \302\2401452.261899: balance_dirty_pages: weight=57% dirtied=128 pause=8\n" - "> > cp-2687 \302\240[006] \302\2401452.268939: balance_dirty_pages: weight=57% dirtied=128 pause=8\n" - "> > cp-2687 \302\240[002] \302\2401452.276932: balance_dirty_pages: weight=57% dirtied=128 pause=8\n" - "> > cp-2687 \302\240[002] \302\2401452.285889: balance_dirty_pages: weight=57% dirtied=128 pause=8\n" + "> > cp-2687 A [002] A 1452.237012: balance_dirty_pages: weight=56% dirtied=128 pause=8\n" + "> > cp-2687 A [002] A 1452.246157: balance_dirty_pages: weight=56% dirtied=128 pause=8\n" + "> > cp-2687 A [006] A 1452.253043: balance_dirty_pages: weight=56% dirtied=128 pause=8\n" + "> > cp-2687 A [006] A 1452.261899: balance_dirty_pages: weight=57% dirtied=128 pause=8\n" + "> > cp-2687 A [006] A 1452.268939: balance_dirty_pages: weight=57% dirtied=128 pause=8\n" + "> > cp-2687 A [002] A 1452.276932: balance_dirty_pages: weight=57% dirtied=128 pause=8\n" + "> > cp-2687 A [002] A 1452.285889: balance_dirty_pages: weight=57% dirtied=128 pause=8\n" "> >\n" "> > CONTROL SYSTEM\n" "> > ==============\n" @@ -149,28 +149,28 @@ "> > because R << B in fig.1).\n" "> >\n" "> > Fig.1 before patch, a heavy dirtier and a light dirtier\n" - "> > \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240R\n" + "> > A A A A A A A A A A A A A A A A A A A A A A A A R\n" "> > ----------------------------------------------+-o---------------------------*--|\n" - "> > \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240L A \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 B \302\240T\n" - "> > \302\240T: bdi_dirty_limit, as returned by bdi_dirty_limit()\n" - "> > \302\240L: T - T/8\n" + "> > A A A A A A A A A A A A A A A A A A A A A A A L A A A A A A A A A A A A A A B A T\n" + "> > A T: bdi_dirty_limit, as returned by bdi_dirty_limit()\n" + "> > A L: T - T/8\n" "> >\n" - "> > \302\240R: bdi_reclaimable + bdi_writeback\n" + "> > A R: bdi_reclaimable + bdi_writeback\n" "> >\n" - "> > \302\240A: task_dirty_limit for a heavy dirtier ~= R ~= L\n" - "> > \302\240B: task_dirty_limit for a light dirtier ~= T\n" + "> > A A: task_dirty_limit for a heavy dirtier ~= R ~= L\n" + "> > A B: task_dirty_limit for a light dirtier ~= T\n" "> >\n" "> > Since each process has its own dirty limit, we reuse A/B for the tasks as\n" "> > well as their dirty limits.\n" "> >\n" "> > If B is a newly started heavy dirtier, then it will slowly gain weight\n" - "> > and A will lose weight. \302\240The task_dirty_limit for A and B will be\n" + "> > and A will lose weight. A The task_dirty_limit for A and B will be\n" "> > approaching the center of region (L, T) and eventually stabilize there.\n" "> >\n" "> > Fig.2 before patch, two heavy dirtiers converging to the same threshold\n" - "> > \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 R\n" + "> > A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A R\n" "> > ----------------------------------------------+--------------o-*---------------|\n" - "> > \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240L \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240A B \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 T\n" + "> > A A A A A A A A A A A A A A A A A A A A A A A L A A A A A A A A B A A A A A A A T\n" "> \n" "> Seems good until now.\n" "> So, What's the problem if two heavy dirtiers have a same threshold?\n" @@ -179,33 +179,33 @@ "\"dd\"s.\n" "\n" "> > Fig.3 after patch, one heavy dirtier\n" - "> > \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240|\n" - "> > \302\240 \302\240throttle_bandwidth ~= bdi_bandwidth \302\240=> \302\240 \302\240 o\n" - "> > \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240| o\n" - "> > \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240| \302\240 o\n" - "> > \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240| \302\240 \302\240 o\n" - "> > \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240| \302\240 \302\240 \302\240 o\n" - "> > \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240| \302\240 \302\240 \302\240 \302\240 o\n" - "> > \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240La| \302\240 \302\240 \302\240 \302\240 \302\240 o\n" + "> > A A A A A A A A A A A A A A A A A A A A A A A A |\n" + "> > A A throttle_bandwidth ~= bdi_bandwidth A => A A o\n" + "> > A A A A A A A A A A A A A A A A A A A A A A A A | o\n" + "> > A A A A A A A A A A A A A A A A A A A A A A A A | A o\n" + "> > A A A A A A A A A A A A A A A A A A A A A A A A | A A o\n" + "> > A A A A A A A A A A A A A A A A A A A A A A A A | A A A o\n" + "> > A A A A A A A A A A A A A A A A A A A A A A A A | A A A A o\n" + "> > A A A A A A A A A A A A A A A A A A A A A A A La| A A A A A o\n" "> > ----------------------------------------------+-+-------------o----------------|\n" - "> > \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240R \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 A \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240T\n" - "> > \302\240T: bdi_dirty_limit\n" - "> > \302\240A: task_dirty_limit \302\240 \302\240 \302\240= T - Wa * T/16\n" - "> > \302\240La: task_throttle_thresh = A - A/16\n" + "> > A A A A A A A A A A A A A A A A A A A A A A A A R A A A A A A A A A A A A A A A T\n" + "> > A T: bdi_dirty_limit\n" + "> > A A: task_dirty_limit A A A = T - Wa * T/16\n" + "> > A La: task_throttle_thresh = A - A/16\n" "> >\n" - "> > \302\240R: bdi_dirty_pages = bdi_reclaimable + bdi_writeback ~= La\n" + "> > A R: bdi_dirty_pages = bdi_reclaimable + bdi_writeback ~= La\n" "> >\n" "> > Now for IO-less balance_dirty_pages(), let's do it in a \"bandwidth control\"\n" "> > way. In fig.3, a soft dirty limit region (La, A) is introduced. When R enters\n" "> > this region, the task may be throttled for J jiffies on every N pages it dirtied.\n" "> > Let's call (N/J) the \"throttle bandwidth\". It is computed by the following formula:\n" "> >\n" - "> > \302\240 \302\240 \302\240 \302\240throttle_bandwidth = bdi_bandwidth * (A - R) / (A - La)\n" + "> > A A A A throttle_bandwidth = bdi_bandwidth * (A - R) / (A - La)\n" "> > where\n" - "> > \302\240 \302\240 \302\240 \302\240A = T - Wa * T/16\n" - "> > \302\240 \302\240 \302\240 \302\240La = A - A/16\n" + "> > A A A A A = T - Wa * T/16\n" + "> > A A A A La = A - A/16\n" "> > where Wa is task weight for A. It's 0 for very light dirtier and 1 for\n" - "> > the one heavy dirtier (that consumes 100% bdi write bandwidth). \302\240The\n" + "> > the one heavy dirtier (that consumes 100% bdi write bandwidth). A The\n" "> > task weight will be updated independently by task_dirty_inc() at\n" "> > set_page_dirty() time.\n" "> \n" @@ -239,6 +239,13 @@ "> Thanks for the great work.\n" "\n" "Thanks,\n" - Fengguang + "Fengguang\n" + "\n" + "--\n" + "To unsubscribe, send a message with 'unsubscribe linux-mm' in\n" + "the body to majordomo@kvack.org. For more info on Linux MM,\n" + "see: http://www.linux-mm.org/ .\n" + "Fight unfair telecom policy in Canada: sign http://dissolvethecrtc.ca/\n" + "Don't email: <a href=mailto:\"dont@kvack.org\"> email@kvack.org </a>" -a59bd5a0eea53e5a3035074f6c510c027e575b0b27a96ec444b9d98c7c78e11a +d68a9513d9b2853cf1da265b2978ba9bf1b14e683ca238d18f3f107f461d02cc
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.