Messages in this thread | | | Date | Fri, 27 Nov 1998 00:03:05 +0100 (CET) | From | MOLNAR Ingo <> | Subject | Re: [2.1.130-3] Page cache DEFINATELY too persistant... feature? |
| |
On Thu, 26 Nov 1998, Linus Torvalds wrote:
> 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/
| |