Ok

On Fri, Aug 2, 2013 at 5:40 PM, Maxim Patlasov [off-list ref] wrote:

07/19/2013 08:50 PM, Miklos Szeredi пишет:

quoted

On Sat, Jun 29, 2013 at 09:45:29PM +0400, Maxim Patlasov wrote:

quoted

quoted

quoted

quoted

From: Pavel Emelyanov <redacted>

quoted

quoted

quoted

quoted

The .writepages one is required to make each writeback request carry more

quoted

quoted

than

quoted

quoted

one page on it. The patch enables optimized behaviour unconditionally,

quoted

quoted

i.e. mmap-ed writes will benefit from the patch even if

quoted

quoted

fc->writeback_cache=0.

quoted

quoted

I rewrote this a bit, so we won't have to do the thing in two passes,

quoted

which

quoted

makes it simpler and more robust.  Waiting for page writeback here is

quoted

wrong

quoted

anyway, see comment above fuse_page_mkwrite().  BTW we had a race there

quoted

because

quoted

fuse_page_mkwrite() didn't take the page lock.  I've also fixed that up

quoted

and

quoted

pushed a series containing these patches up to implementing ->writepages()

quoted

to

quoted

quoted

   git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse.git

quoted

writepages

quoted

quoted

Passed some trivial testing but more is needed.

Thanks a lot for efforts. The approach you implemented looks promising, but

it introduces the following assumption: a page cannot become dirty before we

have a chance to wait on fuse writeback holding the page locked. This is

already true for mmap-ed writes (due to your fixes) and it seems doable for

cached writes as well (like we do in fuse_perform_write). But the assumption

seems to be broken in case of direct read from local fs (e.g. ext4) to a

memory region mmap-ed to a file on fuse fs. See how dio_bio_submit() marks

pages dirty by bio_set_pages_dirty(). I can't see any solution for this

use-case. Do you?

Hmm.  Direct IO on an mmaped file will do get_user_pages() which will

do the necessary page fault magic and ->page_mkwrite() will be called.

At least AFAICS.



The page cannot become dirty through a memory mapping without first

switching the pte from read-only to read-write first.  Page accounting

logic relies on this too.  The other way the page can become dirty is

through write(2) on the fs.  But we do get notified about that too.



Thanks,

Miklos

--

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/