This in preparation for the writable mmap patches for fuse.  I know it

conflicts with
  writeback-remove-unnecessary-wait-in-throttle_vm_writeout.patch
but if this function is to be removed, it doesn't make much sense to

fix it first ;)

---
From: Miklos Szeredi <mszeredi@suse.cz>
By relying on the global diry limits, this can cause a deadlock when

devices are stacked.
If the stacking is done through a fuse filesystem, the __GFP_FS,

__GFP_IO tests won't help: the process doing the allocation doesn't

have any special flag.
So why exactly does this function exist?
Direct reclaim does not _increase_ the number of dirty pages in the

system, so rate limiting it seems somewhat pointless.
There are two cases:
1) File backed pages -> file
  dirty + writeback count remains constant
2) Anonymous pages -> swap
  writeback count increases, dirty balancing will hold back file

  writeback in favor of swap
So the real question is: does case 2 need rate limiting, or is it OK

to let the device queue fill with swap pages as fast as possible?
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>

---
Index: linux/include/linux/writeback.h

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

--- linux.orig/include/linux/writeback.h	2007-10-02 16:55:03.000000000 +0200

+++ linux/include/linux/writeback.h	2007-10-04 13:40:33.000000000 +0200

@@ -94,7 +94,6 @@ static inline void inode_sync_wait(struc

 int wakeup_pdflush(long nr_pages);

 void laptop_io_completion(void);

 void laptop_sync_completion(void);

-void throttle_vm_writeout(gfp_t gfp_mask);
 /* These are exported to sysctl. */

 extern int dirty_background_ratio;

Index: linux/mm/page-writeback.c

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

--- linux.orig/mm/page-writeback.c	2007-10-02 16:55:03.000000000 +0200

+++ linux/mm/page-writeback.c	2007-10-04 13:40:33.000000000 +0200

@@ -497,37 +497,6 @@ void balance_dirty_pages_ratelimited_nr(

 }

 EXPORT_SYMBOL(balance...
[ message continues ]

On Thu, 04 Oct 2007 14:25:22 +0200
This description of the bug-which-is-being-fixed is nowhere near adequate

enough for a reviewer to understand the problem.  This makes it hard to
That's described in the changelog for the patch which added
None of the above.
    [PATCH] vm: pageout throttling
    With silly pageout testcases it is possible to place huge amounts of memory

    under I/O.  With a large request queue (CFQ uses 8192 requests) it is

    possible to place _all_ memory under I/O at the same time.
    This means that all memory is pinned and unreclaimable and the VM gets

    upset and goes oom.
    The patch limits the amount of memory which is under pageout writeout to be

    a little more than the amount of memory at which balance_dirty_pages()

    callers will synchronously throttle.
    This means that heavy pageout activity can starve heavy writeback activity

    completely, but heavy writeback activity will not cause starvation of

    pageout.  Because we don't want a simple `dd' to be causing excessive

    latencies in page reclaim.
afaict that problem is still there.  It is possible to get all of

ZONE_NORMAL dirty on a highmem machine.  With a large queue (or lots of

queues), vmscan can them place all of ZONE_NORMAL under IO.
It could be that we've fixed this problem via other means in the interrim,

but from a quick peek to seems to me that the scanner will still do a 100%

CPU burn when all of a zone's pages are under writeback.
throttle_vm_writeout() should be a per-zone thing, I guess.  Perhaps fixing

that would fix your deadlock.  That's doubtful, but I don't know anything

about your deadlock so I cannot say.
-

Ah, OK.
No, doing the throttling per-zone won't in itself fix the deadlock.
Here's a deadlock example:
Total memory = 32M

/proc/sys/vm/dirty_ratio = 10

dirty_threshold = 3M

ratelimit_pages = 1M
Some program dirties 4M (dirty_threshold + ratelimit_pages) of mmap on

a fuse fs.  Page balancing is called which turns all these into

writeback pages.
Then userspace filesystem gets a write request, and tries to allocate

memory needed to complete the writeout.
That will possibly trigger direct reclaim, and throttle_vm_writeout()

will be called.  That will block until nr_writeback goes below 3.3M

(dirty_threshold + 10%).  But since all 4M of writeback is from the

fuse fs, that will never happen.
Does that explain it better?
Miklos

-

On Fri, 05 Oct 2007 00:39:16 +0200
yup, thanks.
This is a somewhat general problem: a userspace process is in the IO path.

Userspace block drivers, for example - pretty much anything which involves

kernel->userspace upcalls for storage applications.
I solved it once in the past by marking the userspace process as

PF_MEMALLOC and I beleive that others have implemented the same hack.
I suspect that what we need is a general solution, and that the solution

will involve explicitly telling the kernel that this process is one which

actually cleans memory and needs special treatment.
Because I bet there will be other corner-cases where such a process needs

kernel help, and there might be optimisation opportunities as well.
Problem is, any such mark-me-as-special syscall would need to be

privileged, and FUSE servers presently don't require special perms (do

they?)
-

I think just adding nr_cpus * ratelimit_pages to the dirth_thresh in

throttle_vm_writeout() will also solve the problem

On Fri, 05 Oct 2007 09:32:57 +0200
Agreed, that should fix the main latency issues.
--

All Rights Reversed

-

No, and that's a rather important feature, that I'd rather not give

up.  But with the dirty limiting, the memory cleaning really shouldn't

be a problem, as there is plenty of memory _not_ used for dirty file

data, that the filesystem can use during the writeback.
So the only thing the kernel should be careful about, is not to block

on an allocation if not strictly necessary.
Actually a trivial fix for this problem could be to just tweak the

thresholds, so to make the above scenario impossible.  Although I'm

still not convinced, this patch is perfect, because the dirty

threshold can actually change in time...
Index: linux/mm/page-writeback.c

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

--- linux.orig/mm/page-writeback.c      2007-10-05 00:31:01.000000000 +0200

+++ linux/mm/page-writeback.c   2007-10-05 00:50:11.000000000 +0200

@@ -515,6 +515,12 @@ void throttle_vm_writeout(gfp_t gfp_mask

         for ( ; ; ) {

                get_dirty_limits(&background_thresh, &dirty_thresh, NULL, NULL);
+               /*

+                * Make sure the theshold is over the hard limit of

+                * dirty_thresh + ratelimit_pages * nr_cpus

+                */

+               dirty_thresh += ratelimit_pages * num_online_cpus();

+

                 /*

                  * Boost the allowable dirty threshold a bit for page

                  * allocators so they don't get DoS'ed by heavy writers
-

On Fri, 05 Oct 2007 01:26:12 +0200
Can fuse do it?  Perhaps the fs can diddle the server's task_struct at
I don't think I understand that.  Sure, it _shouldn't_ be a problem.  But it
I can probably kind of guess what you're trying to do here.  But if

ratelimit_pages * num_online_cpus() exceeds the size of the offending zone

then things might go bad.
-

No, it's futile.  What if another process is involved (ssh in case of
The problem, I believe is in the memory allocation code, not in fuse.
In the example, memory allocation may be blocking indefinitely,

because we have 4MB under writeback, even though 28MB can still be
I think the admin can do quite a bit of other damage, by setting

dirty_ratio too high.
Maybe this writeback throttling should just have a fixed limit of 80%

ZONE_NORMAL, and limit dirty_ratio to something like 50%.
Miklos

-

fuse is trying to do something which page reclaim was not designed for. 
Well yes.  But we need to work out how, without re-breaking the thing which
Bear in mind that the same problem will occur for the 16MB ZONE_DMA, and

we cannot limit the system-wide dirty-memory threshold to 12MB.
iow, throttle_vm_writeout() needs to become zone-aware.  Then it only

throttles when, say, 80% of ZONE_FOO is under writeback.
Except I don't think that'll fix the problem 100%: if your fuse kernel

component somehow manages to put 80% of ZONE_FOO under writeback (and

remmeber this might be only 12MB on a 16GB machine) then we get stuck again

- the fuse server process (is that the correct terminology, btw?) ends up

waiting upon itself.
I'll think about it a bit.

-

I'm thinking the really_congested thing will also fix this. By only

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
As it stand 110% of dirty limit can already be larger than say zone_dma

(and likely is), so that is not a new bug - and I don't think its the

thing Miklos runs into.
The problem Miklos is seeing (and I, just in a different form), is that

throttle_vm_writeout() gets stuck because balance_dirty_pages() gets

called once every ratelimit_pages (per cpu). So we can have nr_cpus *

ratelimit_pages extra.....
/me thinks
ok I confused myself.
by calling balance_dirty_pages() once every ratelimit_pages (per cpu)

allows for nr_cpus() * ratelimit_pages extra _dirty_ pages. But

balance_dirty_pages() will make it:

  nr_dirty + nr_unstable + nr_writeback < thresh
So even if it writes out all of the dirty pages, we still have:

  nr_unstable + nr_writeback < thresh
So at any one time nr_writeback should not exceed thresh. But it does!?
So how do we end up with more writeback pages than that? should we teach

pdflush about these limits as well?

Ugh.
I think we should rather fix vmscan to not spin when all pages of a

zone are already under writeout.  Which is the _real_ problem,

according to Andrew.
Miklos

-

diff --git a/include/linux/writeback.h b/include/linux/writeback.h

index 4ef4d22..eff2438 100644

--- a/include/linux/writeback.h

+++ b/include/linux/writeback.h

@@ -88,7 +88,7 @@ static inline void wait_on_inode(struct inode *inode)

 int wakeup_pdflush(long nr_pages);

 void laptop_io_completion(void);

 void laptop_sync_completion(void);

-void throttle_vm_writeout(gfp_t gfp_mask);

+void throttle_vm_writeout(struct zone *zone, gfp_t gfp_mask);

=20

 /* These are exported to sysctl. */

 extern int dirty_background_ratio;

diff --git a/mm/page-writeback.c b/mm/page-writeback.c

index eec1481..f949997 100644

--- a/mm/page-writeback.c

+++ b/mm/page-writeback.c

@@ -326,11 +326,8 @@ void balance_dirty_pages_ratelimited_nr(struct address=

_space *mapping,

 }

 EXPORT_SYMBOL(balance_dirty_pages_ratelimited_nr);

=20

-void throttle_vm_writeout(gfp_t gfp_mask)

+void throttle_vm_writeout(struct zone *zone, gfp_t gfp_mask)

 {

-	long background_thresh;

-	long dirty_thresh;

-

 	if ((gfp_mask & (__GFP_FS|__GFP_IO)) !=3D (__GFP_FS|__GFP_IO)) {

 		/*

 		 * The caller might hold locks which can prevent IO completion

@@ -342,17 +339,16 @@ void throttle_vm_writeout(gfp_t gfp_mask)

 	}

=20

         for ( ; ; ) {

-		get_dirty_limits(&background_thresh, &dirty_thresh, NULL);

+		unsigned long thresh =3D zone_page_state(zone, NR_ACTIVE) +

+			zone_page_state(zone, NR_INACTIVE);

=20

-                /*

-                 * Boost the allowable dirty threshold a bit for page

-                 * allocators so they don't get DoS'ed by heavy writers

-                 */

-                dirty_thresh +=3D dirty_thresh / 10;      /* wheeee... */

+		/*

+		 * wait when 75% of the zone's pages are under writeback

+		 */

+		thresh -=3D thresh >> 2;

+		if (zone_page_state(zone, NR_WRITEBACK) < thresh)

+			break;

=20

-                if (global_page_state(NR_UNSTABLE_NFS) +

-			global_page_state(NR_WRITEBACK) <=3D dirty_thresh)

-                        	break;

                ...
[ message continues ]

I think that's an improvement in all respects.
However it still does not generally address the deadlock scenario: if

there's a small DMA zone, and fuse manages to put all of those pages

under writeout, then there's trouble.
But it's not really fuse specific.  If it was a normal filesystem that

did that, and it needed a GFP_DMA allocation for writeout, it is in

trouble also, as that allocation would fail (at least no deadlock).
Or is GFP_DMA never used by fs/io writeout paths?
Miklos

-

I agree that its not complete. (hence the lack of sign-off etc.)
'normally' writeback pages just need an interrupt to signal the stuff is

written back. ie. the writeback completion path is atomic.=20
 [ result of the thinking below -- the above is esp. true for swap pages

   - so maybe we should ensure that !swap traffic can never exceed this

   75% - that way, swap can always us get out of a tight spot ]
Maybe we should make that a requirement, although I see how that becomes

rather hard for FUSE (which is where Andrews PF_MEMALLOC suggestion

comes from - but I really dislike PF_MEMALLOC exposed to userspace).
Limiting FUSE to say 50% (suggestion from your other email) sounds like

a horrible hack to me. - Need more time to think on this.
.. o O [ process of thinking ]
While I think, I might as well tell the problem I had with

throttle_vm_writeout(), which is nfs unstable pages. Those don't go away

by waiting for it - as throttle_vm_writeout() does. So once you have an

excess of those, you're stuck as well.
In this patch I totally ignored unstable, but I'm not sure that's the

proper thing to do, I'd need to figure out what happens to an unstable

page when passed into pageout() - or if its passed to pageout at all.
If unstable pages would be passed to pageout(), and it would properly

convert them to writeback and clean them, then there is nothing wrong.
(Trond?)

Why would we want to do that? That would be a hell of a lot of work

(locking pages, setting flags, unlocking pages, ...) for absolutely no

reason.
Unstable writes are writes which have been sent to the server, but which

haven't been written to disk on the server. A single RPC command is then

sent (COMMIT) which basically tells the server to call fsync(). After

that is successful, we can free up the pages, but we do that with no

extra manipulation of the pages themselves: no page locks, just removal

from the NFS private radix tree, and freeing up of the NFS private

structures.
We only need to touch the pages again in the unlikely case that the

COMMIT fails because the server has rebooted. In this case we have to

resend the writes, and so the pages are marked as dirty, so we can go

through the whole writepages() rigmarole again...
So, no. I don't see sending pages through pageout() as being at all

helpful.
Trond
-

Well, the thing is, we throttle pageout in throttle_vm_writeout(). As it

stand we can deadlock there because it just waits for the numbers to

drop, and unstable pages don't automagically dissapear. Only

write_inodes() - normally called from balance_dirty_pages() will call

COMMIT.
So my thought was that calling pageout() on an unstable page would do

the COMMIT - we're low on memory, otherwise we would not be paging, so

getting rid of unstable pages seems to make sense to me.
-

I wonder whether

        if (!bdi_nr_writeback)

                break;
I guess "many unstable pages" would be better if we are taking this way.
-

Why not rather track which mappings have large numbers of outstanding

unstable writes at the VM level, and then add some form of callback to

allow it to notify the filesystem when it needs to flush them out?
Cheers

  Trond
-

BTW: Please note that at least in the case of NFS, you will have to

allow for the fact that the filesystem may not be _able_ to cause the

numbers to drop. If the server is unavailable, then we're may be stuck

in unstable page limbo for quite some time.
Trond
-

That would be nice, its just that the pageout throttling is not quite
Agreed, it would be nice if that is handled is such a manner that it

does not take down all other paging.
The regular write path that only bothers with balance_dirty_pages()

already does this nicely.
-

I don't really understand all that page balancing stuff, but I think

this will probably never or very rarely happen, because the allocator

will prefer the bigger zones, and the dirty page limiting will not let

the bigger zones get too full of dirty pages.
And even it can happen, it's not necessarily a fuse-only thing.
It makes tons of sense to make sure, that we don't fully dirty _any_

specialized zone.  One special zone group are the low-memory pages.

And currently balance_dirty_pages() makes sure we don't fill that up

with dirty file backed pages.  So something like that should make

sense for other special zones like DMA as well.
I'm not saying it's trivial, or even possible to implement, just

thinking...
Miklos

-

And the only way to solve that AFAICS, is to make sure fuse never uses

more than e.g. 50% of _any_ zone for page cache.  And that may need

some tweaking in the allocator...
Miklos

-

Miklos> And the only way to solve that AFAICS, is to make sure fuse

Miklos> never uses more than e.g. 50% of _any_ zone for page cache.

Miklos> And that may need some tweaking in the allocator...
So what happens if I have three different FUSE mounts, all under heavy

write pressure?  It's not a FUSE problem, it's a VM problem as far as

I can see.   All I did was extrapolate from the 50% number (where did

that come from?) and triple it to go over 100%, since we obviously

shouldn't take 100% of any zone, right?
So the real cure is to have some way to rate limit Zone usage, making

it harder and harder to allocate in a zone as the zone gets more and

more full.  But how do you do this in a non-deadlocky way?  
Buy hey, I'm not that knowledgeable about the VM.

-

Because balance_dirty_pages() maintains:
 nr_dirty + nr_unstable + nr_writeback <=20

	total_dirty + nr_cpus * ratelimit_pages
throttle_vm_writeout() _should_ not deadlock on that, unless you're

caught in the error term: nr_cpus * ratelimit_pages.=20
Which can only happen when it is larger than 10% of dirty_thresh.
Which is even more unlikely since it doesn't account nr_dirty (as I

think it should).
As for 2), yes I think having a limit on the total number of pages in

flight is a good thing. But that said, there might be better ways to do

that.

And it does get caught on that in small memory machines.  This

deadlock is easily reproducable on a 32MB UML instance.  I haven't yet

tested with the per-bdi patches, but I don't think they make a
I think nr_dirty is totally irrelevant.  Since we don't care about
Sure, if we do need to globally limit the number of under-writeback

pages, then I think we need to do it independently of the dirty

accounting.
Miklos

-

Ah, but its correct to have since we compare against dirty_thresh, which

is defined to be a unit of nr_dirty + nr_unstable + nr_writeback. if we
for my swapping over network thingies I need to put a bound on the

amount of outgoing traffic in flight because that bounds the amount of
It need not be global, it could be per BDI as well, but yes.

Yeah, I guess the point of the function was to limit nr_write to
I guess you will have some request queue with limited length, no?
The main problem seems to be if devices use up all the reserved memory

for queuing write requests.  Limiting the in-flight pages is a very

crude way to solve this, the assumptions are:
O: overhead as a fraction of the request size

T: total memory

R: reserved memory

T-R: may be full of anon pages
so if (T-R)*O > R  we are in trouble.
if we limit the writeback memory to L and L*O < R we are OK.  But we

don't know O (it's device dependent).  We can make an estimate

calculate L based on that, but that will be a number totally
For per-bdi limits we have the queue length.
Miklod

-

Yeah, I'm guestimating O on a per device basis, but I agree that the

current ratio limiting is quite crude. I'm not at all sorry to see

throttle_vm_writeback() go, I just wanted to make a point that what it

does is not quite without merrit - we agree that it can be done better
Agreed, except for:
static int may_write_to_queue(struct backing_dev_info *bdi)

{

	if (current->flags & PF_SWAPWRITE)

		return 1;

	if (!bdi_write_congested(bdi))

		return 1;

	if (bdi == current->backing_dev_info)

		return 1;

	return 0;

}
Which will write to congested queues. Anybody know why?
-

Yes.  So what is it to be?
Is limiting by device queues enough?
Or do we need some global limit?
If so, the cleanest way I see is to separately account and limit

swap-writeback pages, so the global counters don't interfere with the

limiting.
This shouldn't be hard to do, as we have the per-bdi writeback

counting infrastructure already, and also a pseudo bdi for swap in

swapper_space.backing_dev_info.
Miklos

-

commit c4e2d7ddde9693a4c05da7afd485db02c27a7a09

Author: akpm <akpm>

Date:   Sun Dec 22 01:07:33 2002 +0000
    [PATCH] Give kswapd writeback higher priority than pdflush
    The `low latency page reclaim' design works by preventing page

    allocators from blocking on request queues (and by preventing them from

    blocking against writeback of individual pages, but that is immaterial

    here).
    This has a problem under some situations.  pdflush (or a write(2)

    caller) could be saturating the queue with highmem pages.  This

    prevents anyone from writing back ZONE_NORMAL pages.  We end up doing

    enormous amounts of scenning.
    A test case is to mmap(MAP_SHARED) almost all of a 4G machine's memory,

    then kill the mmapping applications.  The machine instantly goes from

    0% of memory dirty to 95% or more.  pdflush kicks in and starts writing

    the least-recently-dirtied pages, which are all highmem.  The queue is

    congested so nobody will write back ZONE_NORMAL pages.  kswapd chews

    50% of the CPU scanning past dirty ZONE_NORMAL pages and page reclaim

    efficiency (pages_reclaimed/pages_scanned) falls to 2%.
    So this patch changes the policy for kswapd.  kswapd may use all of a

    request queue, and is prepared to block on request queues.
    What will now happen in the above scenario is:
    1: The page alloctor scans some pages, fails to reclaim enough

       memory and takes a nap in blk_congetion_wait().
    2: kswapd() will scan the ZONE_NORMAL LRU and will start writing

       back pages.  (These pages will be rotated to the tail of the

       inactive list at IO-completion interrupt time).
       This writeback will saturate the queue with ZONE_NORMAL pages.

       Conveniently, pdflush will avoid the congested queues.  So we end up

       writing the correct pages.
    In this test, kswapd CPU utilisation falls from 50% to 2%, page reclaim

    efficiency rises from 2% to 40% and ...
[ message continues ]

Sorry, I cannot not understand it. We now have balanced aging between

zones. So the page allocations are expected to distribute proportionally
We may see the same problem and improvement in the absent of 'all

writeback goes to one zone' assumption.
The problem could be:

- dirty_thresh is exceeded, so balance_dirty_pages() starts syncing

  data and quickly _congests_ the queue;

- dirty pages are slowly but continuously turned into clean pages by

  balance_dirty_pages(), but they still stay in the same place in LRU;

- the zones are mostly dirty/writeback pages, kswapd has a hard time

  finding the randomly distributed clean pages;

- kswapd cannot do the writeout because the queue is congested!
The improvement could be:

- kswapd is now explicitly preferred to do the writeout;

- the pages written by kswapd will be rotated and easy for kswapd to reclaim;

- it becomes possible for kswapd to wait for the congested queue,

  instead of doing the vmscan like mad.
The congestion wait looks like a pretty natural way to throttle the kswapd.

Instead of doing the vmscan at 1000MB/s and actually freeing pages at

60MB/s(about the write throughput), kswapd will be relaxed to do vmscan at

maybe 150MB/s.
Fengguang
-

On Fri, 5 Oct 2007 20:30:28 +0800
Sure, but we don't have one disk queue per disk per zone!  The queue is

shared by all the zones.  So if writeback from one zone has filled the

queue up, the kernel can't write back data from another zone.
(Well, it can, by blocking in get_request_wait(), but that causes long and
Or someone ran fsync(), or pdflush is writing back data because it exceeded
Yeah.  In 2.4 and early 2.5, page-reclaim (both direct reclaim and kswapd,

iirc) would throttle by waiting on writeout of a particular page.  This was

a poor design, because writeback against a *particular* page can take

anywhere from one millisecond to thirty seconds to complete, depending upon

where the disk head is and all that stuff.
The critical change I made was to switch the throttling algorithm from

"wait for one page to get written" to "wait for _any_ page to get written".

 Becaue reclaim really doesn't care _which_ page got written: we want to

wake up and start scanning again when _any_ page got written.
That's what congestion_wait() does.
It is pretty crude.  It could be that writeback completed against pages which

aren't in the correct zone, or it could be that some other task went and

allocated the just-cleaned pages before this task can get running and

reclaim them, or it could be that the just-written-back pages weren't

reclaimable after all, etc.
It would take a mind-boggling amount of logic and locking to make all this

100% accurate and the need has never been demonstrated.  So page reclaim

presently should be viewed as a polling algorithm, where the rate of
Something like that.
The critical numbers to watch are /proc/vmstat's *scan* and *steal*.  Look:
akpm:/usr/src/25> uptime

 10:08:14 up 10 days, 16:46, 15 users,  load average: 0.02, 0.05, 0.04

akpm:/usr/src/25> grep steal /proc/vmstat

pgsteal_dma 0

pgsteal_dma32 0

pgsteal_normal 0

pgsteal_high 0

pginodesteal 0

kswapd_steal 1218698

kswapd_inodesteal 266847

akpm:/usr/src/25> grep scan /proc/vmsta...
[ message continues ]

Hmm, that's a problem. But I guess when one zone is full, other zones
I guess PF_SWAPWRITE processes still have good probability to stuck in

get_request_wait().  Because balance_dirty_pages() are allowed to

disregard the congestion.  It will be exhausting the available request

slots all the time.
Signed-off-by: Fengguang Wu <wfg@mail.ustc.edu.cn>

---

 mm/page-writeback.c |    1 +

 1 file changed, 1 insertion(+)
--- linux-2.6.23-rc8-mm2.orig/mm/page-writeback.c

+++ linux-2.6.23-rc8-mm2/mm/page-writeback.c

@@ -400,6 +400,7 @@ static void balance_dirty_pages(struct a

 			.sync_mode	= WB_SYNC_NONE,

 			.older_than_this = NULL,

 			.nr_to_write	= write_chunk,

+			.nonblocking	= 1,

 			.range_cyclic	= 1,
Nice tool!

I've been watching the raw numbers by writing scripts. This one can be

written as:
#!/bin/bash
while true; do

	while read a b

	do

		eval $a=$b

	done < /proc/vmstat
	uptime=$(</proc/uptime)
	scan=$((

		pgscan_kswapd_dma +

		pgscan_kswapd_dma32 +

		pgscan_kswapd_normal +

		pgscan_kswapd_high +

		pgscan_direct_dma +

		pgscan_direct_dma32 +

		pgscan_direct_normal +

		pgscan_direct_high

		))
	steal=$((

		pgsteal_dma +

		pgsteal_dma32 +

		pgsteal_normal +

		pgsteal_high

		))
	ratio=$((100*steal/(scan+1)))
	echo -e "$uptime\t$ratio%\t$steal\t$scan"

        sleep 1;

done
Not surprisingly, I see nice numbers on my desktop:
Thank you for the nice tip :-)
Fengguang
-

with highmem >> normal, and user pages preferring highmem, this will
So request queue's have a limit above the congestion level on which they

will block?
I could do that.
-

On Thu, 04 Oct 2007 20:10:10 +0200
I guess first you'd need to be able to reproduce the problem which that

patch fixed, then check that it remains fixed.
Sigh.  That problem was fairly subtle.  We could re-break reclaim in

this way and not find out about it for six months.  There's a lesson here.

Several.

-