> > Currently, we use this on virtually anything that trigggers writepage()> > with the wbc->for_reclaim flag set.> > Why? Sorry, I still do not understand the effect which you're trying to> achieve? I thought it was an efficiency thing: send more traffic via> writepages(). But your other comments seem to indicate that this is not> the primary reason.

That is the primary reason. Under NFS, writing is a 2 stage process:

- Stage 1: "schedule" the page for writing. Basically this entailscreating an nfs_page struct for each dirty page and putting this on theNFS private list of dirty pages. - Stage 2: "flush" the NFS private list of dirty pages. This involvescoalescing contiguous nfs_page structs into chunks of size "wsize", andactually putting them on the wire in the form of RPC requests.

writepage() only deals with one page at a time, so it will work fine fordoing stage 1.If you also try force it to do stage 2, then you will end up with chunksof size <= PAGE_CACHE_SIZE because there will only be 1 page on the NFSprivate list of dirty pages. In practice this again means that youusually have to send 8 times as many RPC requests to the server in orderto process the same amount of data.

This is why I'd like to try to leave stage 2) to writepages().

Now normally, that is not a problem, since the actual calls towritepage() are in fact made by means of a call to generic_writepages()from within nfs_writepages(), so I can do all the correct things onceI'm done with generic_writepages().

However shrink_cache() (where the MM calls writepage() directly) needsto be treated specially, since that is not wrapped by a writepages()call. In that case, we return WRITEPAGE_ACTIVATE and wait for pdflush tocall writepages().