> > This is probably a > > reasonable thing to do but it doesn't feel like the right place. I > > think get_dirty_limits should return the raw threshold, and > > balance_dirty_pages should do both tests - the bdi-local test and the > > system-wide test. > > Ok, that makes sense I guess.
Well, my narrow minded world view says it's not such a good idea, because it would again introduce the deadlock scenario, we're trying to avoid. In a sense allowing a queue to go over the global limit just a little bit is a good thing. Actually the very original code does that: if writeback was started for "write_chunk" number of pages, then we allow "ratelimit" (8) _new_ pages to be dirtied, effectively ignoring the global limit. That's why I've been saying, that the current code is so unfair: if there are lots of dirty pages to be written back to a particular device, then balance_dirty_pages() allows the dirty producer to make even more pages dirty, but if there are _no_ dirty pages for a device, and we are over the limit, then that dirty producer is allowed absolutely no new dirty pages until the global counts subside. I'm still not quite sure what purpose the above "soft" limiting serves. It seems to just give advantage to writers, which managed to accumulate lots of dirty pages, and then can convert that into even more dirtyings. Would it make sense to remove this behavior, and ensure that balance_dirty_pages() doesn't return until the per-queue limits have been complied with? Miklos - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
