On Thu, 2007-10-04 at 14:25 +0200, Miklos Szeredi wrote: > This in preparation for the writable mmap patches for fuse. I know it > conflicts with > > writeback-remove-unnecessary-wait-in-throttle_vm_writeout.patch > > but if this function is to be removed, it doesn't make much sense to > fix it first ;) > --- > > From: Miklos Szeredi <[email protected]> > > By relying on the global diry limits, this can cause a deadlock when > devices are stacked. > > If the stacking is done through a fuse filesystem, the __GFP_FS, > __GFP_IO tests won't help: the process doing the allocation doesn't > have any special flag. > > So why exactly does this function exist? > > Direct reclaim does not _increase_ the number of dirty pages in the > system, so rate limiting it seems somewhat pointless. > > There are two cases: > > 1) File backed pages -> file > > dirty + writeback count remains constant > > 2) Anonymous pages -> swap > > writeback count increases, dirty balancing will hold back file > writeback in favor of swap > > So the real question is: does case 2 need rate limiting, or is it OK > to let the device queue fill with swap pages as fast as possible? Because balance_dirty_pages() maintains: nr_dirty + nr_unstable + nr_writeback < total_dirty + nr_cpus * ratelimit_pages throttle_vm_writeout() _should_ not deadlock on that, unless you're caught in the error term: nr_cpus * ratelimit_pages. Which can only happen when it is larger than 10% of dirty_thresh. Which is even more unlikely since it doesn't account nr_dirty (as I think it should). As for 2), yes I think having a limit on the total number of pages in flight is a good thing. But that said, there might be better ways to do that.
Attachment:
signature.asc
Description: This is a digitally signed message part
- Follow-Ups:
- Re: [PATCH] remove throttle_vm_writeout()
- From: Miklos Szeredi <[email protected]>
- Re: [PATCH] remove throttle_vm_writeout()
- References:
- [PATCH] remove throttle_vm_writeout()
- From: Miklos Szeredi <[email protected]>
- [PATCH] remove throttle_vm_writeout()
- Prev by Date: Re: [PATCH 1/3] signal(i386): alternative signal stack wraparound occurs
- Next by Date: Re: Accessing 64-bit BARs
- Previous by thread: [PATCH] remove throttle_vm_writeout()
- Next by thread: Re: [PATCH] remove throttle_vm_writeout()
- Index(es):
 |