> Now, the same should be true of "bdflush" - we could on bdflush to
> generally keep the number of dirty pages down, and to balance the peak
> usage so that we don't get bouts of extremely heavy disk activity (like we
> did with the old "update" process). But when we really need to write stuff
> out, the page-out process should really try to free stuff up itself.
the problem with bdlush is that it's extremely easy to dirty a large
portion of the buffer cache. This process can be much faster than the
typical period of time in which bdflush can react and make a difference. I
think we have a similar problem with the page cache too, but the
difference is that the page cache is either nonshared and dirty, or shared
and clean, but seldom shared and writable. The buffer cache is 'shared' in
a sense (if we use your analogy), and is easy to dirtyfy.
in theory, if some user application knows the contents of the buffer cache
exactly, it can dirty some insane amount of pages before bdflush even has
a chance to run. Even if bdflush runs, we are already full of dirty pages,
and it takes time to write them out. (and bdflush starts to clash with
kswapd in the typical 'one disk system' case, which slows down the
cleaning of buffer cache pages even more)
throttling at the source of dirtyfication (ie. in mark_buffer_dirty())
makes sense because if you think about it, changing a clean buffer page
into dirty actually increases memory pressure directly. (it changes an
easily freeable page into a locked down page, which is basically an
allocation, a page fault in a sense). So to me it makes sense to apply VM
balancing there. Kicking bdflush already happens, but on the spot
throttling makes sense also because the implicit 'allocation' goes around
normal VM balancing rules and throttling mechanizms.
i think we have the same problem in the page cache too, but it doesnt
happen often in RL.
-- mingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/