Messages in this thread | | | Date | Wed, 30 Oct 2013 10:07:08 +0000 (UTC) | From | "Artem S. Tashkinov" <> | Subject | Re: Disabling in-memory write cache for x86-64 in Linux II |
| |
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?
| |