Re: [VM PATCH 2.6.6-rc3-bk5] Dirty balancing in the presence of mapped pages

From: Bill Davidsen
Date: Sun May 09 2004 - 12:19:56 EST

Nick Piggin wrote:

So we need to understand why it was written, and what effects were
observed, with what workload, and all that good stuff.

I guess it is an attempt to do somewhat better at dirty page accounting
for mmap'ed pages. The balance_dirty_pages_ratelimited writeout path
also has the same problem as you describe. Maybe usage patterns means
this is less of an issue here?

But I suppose it wouldn't be nice to change without seeing some
improvement somewhere.

Lots of issues here, writing in random blocks can lead to fragmentation if the data is newly allocated, but won't change fragmenting if the page mapped is alread allocated on the disk.

Is it practical or desirable to be writing mapped pages of allready allocated files back more readily, since it avoid all the allocation issues? But you still need to limit dirty pages, so at some point it will be necessary to do the allocation, preferably in an optimal way.

It doesn't do the wakeup_bdflush thing, but that sounds
like a good idea. What does wakeup_bdflush(-1) mean?

It appears that it will cause pdflush to write out down to

Yeah. So wakeup_bdflush(0) would be more consistent?

bill davidsen <davidsen@xxxxxxx>
CTO TMR Associates, Inc
Doing interesting things with small computers since 1979
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at