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
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 http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/