On Tue 27-07-10 11:59:41, Wu Fengguang wrote: > > > This patch slightly changes behavior by replacing clip_bdi_dirty_limit() > > > with the explicit check (nr_reclaimable + nr_writeback >= dirty_thresh) > > > to avoid exceeding the dirty limit. Since the bdi dirty limit is mostly > > > accurate we don't need to do routinely clip. A simple dirty limit check > > > would be enough. > > > > > > The check is necessary because, in principle we should throttle > > > everything calling balance_dirty_pages() when we're over the total > > > limit, as said by Peter. > > > > > > We now set and clear dirty_exceeded not only based on bdi dirty limits, > > > but also on the global dirty limits. This is a bit counterintuitive, but > > > the global limits are the ultimate goal and shall be always imposed. > > Thinking about this again - what you did is rather big change for systems > > with more active BDIs. For example if I have two disks sda and sdb and > > write for some time to sda, then dirty limit for sdb gets scaled down. > > So when we start writing to sbd we'll heavily throttle the threads until > > the dirty limit for sdb ramps up regardless of how far are we to reach the > > global limit... > > The global threshold check is added in place of clip_bdi_dirty_limit() > for safety and not intended as a behavior change. If ever leading to > big behavior change and regression, that it would be indicating some > too permissive per-bdi threshold calculation. > > Did you see the global dirty threshold get exceeded when writing to 2+ > devices? Occasional small exceeding should be OK though. I tried the > following debug patch and see no warnings when doing two concurrent cp > over local disk and NFS. Oops, sorry. I've misread the code. You're right. There shouldn't be a big change in the behavior. Honza -- Jan Kara <jack@xxxxxxx> SUSE Labs, CR -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxxx For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx"> email@xxxxxxxxx </a>