Date: Sat, 30 Oct 2010 11:16:03 +0300 From: Andriy Gapon <avg@icyb.net.ua> To: Artemiev Igor <ai@kliksys.ru> Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org Subject: Re: 8.1-STABLE: zfs and sendfile: problem still exists Message-ID: <4CCBD443.7010305@icyb.net.ua> In-Reply-To: <20101029175105.GB18613@two.kliksys.ru> References: <3D1C350B94A44E5D95BAA1596D1EBF13@vosz.local> <20101029090417.GA17537@two.kliksys.ru> <4CCABFC2.3040701@icyb.net.ua> <4CCADD37.7000306@icyb.net.ua> <20101029152602.GA18613@two.kliksys.ru> <4CCAF0EB.4080001@icyb.net.ua> <20101029175105.GB18613@two.kliksys.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
on 29/10/2010 20:51 Artemiev Igor said the following:
> On Fri, Oct 29, 2010 at 07:06:03PM +0300, Andriy Gapon wrote:
>> Probably yes, but have to be careful there.
>> First, do vm_page_grab only for UIO_NOCOPY case.
>> Second, the first page is already "shared busy" after vm_page_io_start() call in
>> kern_sendfile; so you might need VM_ALLOC_IGN_SBUSY for that page to avoid a deadlock.
>
> RELENG_8 doesn`t have VM_ALLOC_IGN_SBUSY, it appeared only in HEAD.
> Can you review this patch, Whether correctly I have understood? (didnt test it yet)
>
> --- sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c.orig 2010-10-29 18:18:23.921078337 +0200
> +++ sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c 2010-10-29 19:23:48.142513084 +0200
> @@ -449,7 +449,7 @@
> int bytes = MIN(PAGESIZE - off, len);
>
> again:
> - if ((m = vm_page_lookup(obj, OFF_TO_IDX(start))) != NULL &&
> + if (uio->uio_segflg != UIO_NOCOPY && (m = vm_page_lookup(obj, OFF_TO_IDX(start))) != NULL &&
> vm_page_is_valid(m, off, bytes)) {
> if (vm_page_sleep_if_busy(m, FALSE, "zfsmrb"))
> goto again;
> @@ -464,7 +464,7 @@
> uiomove_fromphys(&m, off, bytes, uio);
> VM_OBJECT_LOCK(obj);
> vm_page_wakeup(m);
> - } else if (m != NULL && uio->uio_segflg == UIO_NOCOPY) {
> + } else if (uio->uio_segflg == UIO_NOCOPY) {
> /*
> * The code below is here to make sendfile(2) work
> * correctly with ZFS. As pointed out by ups@
> @@ -472,11 +472,9 @@
> * but it pessimize performance of sendfile/UFS, that's
> * why I handle this special case in ZFS code.
> */
> - KASSERT(off == 0,
> - ("unexpected offset in mappedread for sendfile"));
> - if (vm_page_sleep_if_busy(m, FALSE, "zfsmrb"))
> - goto again;
> - vm_page_busy(m);
> + if((m = vm_page_lookup(obj, OFF_TO_IDX(start))) == NULL || !vm_page_is_valid(m, off, bytes))
> + m = vm_page_grab(obj, OFF_TO_IDX(start), VM_ALLOC_NORMAL|VM_ALLOC_RETRY);
> +
> VM_OBJECT_UNLOCK(obj);
> if (dirbytes > 0) {
> error = dmu_read_uio(os, zp->z_id, uio,
Or maybe something like the following?
It looks a little bit cleaner to me, but still is not perfect, as I have not
handled unnecessary busy-ing of the pages where something more lightweight could
have sufficed (e.g. wiring and shared busying).
Index: sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c
===================================================================
--- sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c (revision 214318)
+++ sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c (working copy)
@@ -67,6 +67,7 @@
#include <sys/sf_buf.h>
#include <sys/sched.h>
#include <sys/acl.h>
+#include <vm/vm_pageout.h>
/*
* Programming rules.
@@ -464,7 +465,7 @@
uiomove_fromphys(&m, off, bytes, uio);
VM_OBJECT_LOCK(obj);
vm_page_wakeup(m);
- } else if (m != NULL && uio->uio_segflg == UIO_NOCOPY) {
+ } else if (uio->uio_segflg == UIO_NOCOPY) {
/*
* The code below is here to make sendfile(2) work
* correctly with ZFS. As pointed out by ups@
@@ -476,6 +477,16 @@
("unexpected offset in mappedread for sendfile"));
if (vm_page_sleep_if_busy(m, FALSE, "zfsmrb"))
goto again;
+ if (m == NULL) {
+ m = vm_page_alloc(obj, OFF_TO_IDX(start),
+ VM_ALLOC_NOBUSY | VM_ALLOC_SYSTEM);
+ if (m == NULL) {
+ VM_OBJECT_UNLOCK(obj);
+ VM_WAIT;
+ VM_OBJECT_LOCK(obj);
+ goto again;
+ }
+ }
vm_page_busy(m);
VM_OBJECT_UNLOCK(obj);
if (dirbytes > 0) {
--
Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4CCBD443.7010305>