Oct 30, 2013 02:41:01 AM, Jack wrote: On Fri 25-10-13 19:37:53, Ted Tso wrote: >> Sure, although I wonder if it would be worth it calcuate some kind of >> rolling average of the write bandwidth while we are doing writeback, >> so if it turns out we got unlucky with the contents of the first 100MB >> of dirty data (it could be either highly random or highly sequential) >> the we'll eventually correct to the right level. > We already do average measured throughput over a longer time window and >have kind of rolling average algorithm doing some averaging. > >> This means that VM would have to keep dirty page counters for each BDI >> --- which I thought we weren't doing right now, which is why we have a >> global vm.dirty_ratio/vm.dirty_background_ratio threshold. (Or do I >> have cause and effect reversed? :-) > And we do currently keep the number of dirty & under writeback pages per >BDI. We have global limits because mm wants to limit the total number of dirty >pages (as those are harder to free). It doesn't care as much to which device >these pages belong (although it probably should care a bit more because >there are huge differences between how quickly can different devices get rid >of dirty pages).
This might sound like an absolutely stupid question which makes no sense at all, so I want to apologize for it in advance, but since the Linux kernel lacks revoke(), does that mean that dirty buffers will always occupy the kernel memory if I for instance remove my USB stick before the kernel has had the time to flush these buffers? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/