On Tue, Sep 08, 2009 at 12:31:49PM -0400, Chris Mason wrote: > On Tue, Sep 08, 2009 at 05:41:32PM +0200, Nick Piggin wrote: > > It hasn't fallen completely off my radar. fsblock has the same issue > > (although I've just been ignoring gup writes into fsblock fs for the > > time being). > > Ok, I'll change my detection code a bit then. OK. > > I have a basic idea of what to do... It would be nice to change calling > > convention of get_user_pages and take the page lock. Database people might > > scream, in which case we could only take the page lock for filesystems that > > define ->page_mkwrite (so shared mem segments avoid the overhead). Lock > > ordering might get a bit interesting, but if we can have callers ensure they > > always submit and release partially fulfilled requirests, then we can always > > trylock them. > > I think everyone will have page_mkwrite eventually, at least everyone > who the databases will care about ;) Ah, the problem is not where the DIO write goes, it's where the read goes :) (ie. the read writes into get_user_pages pages). So for databases this should typically be shared memory segments I'd say (tmpfs), or maybe anonymous memory. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
