Messages in this thread | | | Subject | Re: RFC - how to balance Dirty+Writeback in the face of slow writeback. | From | Trond Myklebust <> | Date | Thu, 17 Aug 2006 12:18:52 -0400 |
| |
On Thu, 2006-08-17 at 08:30 -0700, Andrew Morton wrote: > On Thu, 17 Aug 2006 09:21:51 -0400 > Trond Myklebust <trond.myklebust@fys.uio.no> wrote: > > Exactly how would a request limit help? All that boils down to is having > > the VM monitor global_page_state(NR_FILE_DIRTY) versus monitoring > > global_page_state(NR_FILE_DIRTY)+global_page_state(NR_WRITEBACK). > > > > I assume that if NFS is not limiting its NR_WRITEBACK consumption and block > devices are doing so, we could get in a situation where NFS hogs all of the > fixed-size NR_DIRTY+NR_WRITEBACK resource at the expense of concurrent > block-device-based writeback.
Since NFS has no control over NR_DIRTY, how does controlling NR_WRITEBACK help? The only resource that NFS shares with the block device writeout queues is memory.
IOW: The resource that needs to be controlled is the dirty pages, not the write-out queue. Unless you can throttle back on the creation of dirty NFS pages in the first place, then the potential for unfairness will exist.
Trond
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |