Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 18 Oct 2012 19:42:18 +0300
From:      Konstantin Belousov <kostikbel@gmail.com>
To:        John Baldwin <jhb@freebsd.org>
Cc:        freebsd-hackers@freebsd.org, Tristan Verniquet <tris_vern@hotmail.com>
Subject:   Re: syncing large mmaped files
Message-ID:  <20121018164218.GR35915@deviant.kiev.zoral.com.ua>
In-Reply-To: <201210180939.34861.jhb@freebsd.org>
References:  <SNT124-W20F26CF7B468F7F09B9B4983760@phx.gbl> <20121018083537.GQ35915@deviant.kiev.zoral.com.ua> <201210180939.34861.jhb@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help

--DI3e56nQDAJ1LWZd
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Oct 18, 2012 at 09:39:34AM -0400, John Baldwin wrote:
> On Thursday, October 18, 2012 4:35:37 am Konstantin Belousov wrote:
> > On Thu, Oct 18, 2012 at 10:08:22AM +1000, Tristan Verniquet wrote:
> > >=20
> > > I want to work with large (1-10G) files in memory but eventually sync
> > > them back out to disk. The problem is that the sync process appears to
> > > lock the file in kernel for the duration of the sync, which can run
> > > into minutes. This prevents other processes from reading from the file
> > > (unless they already have it mapped) for this whole time. Is there
> > > any way to prevent this? I think I read in a post somewhere about
> > > openbsd implementing partial-writes when it hits a file with lots of
> > > dirty pages in order to prevent this. Is there anything available for
> > > FreeBSD or is there another way around it?
> > >
> > No, currently the vnode lock is held exclusive for the whole duration
> > of the msync(2) syscall or its analog from the syncer.
> >=20
> > Making a change to periodically drop the vnode lock in
> > vm_object_page_clean() might be possible, but requires the benchmarking
> > to make sure that we do not pessimize the common case. Also, this opens
> > a possibility for the vnode reclamation meantime.
>=20
> You can simulate this in userland by breaking up your msync() into multip=
le
> msync() calls where each call just syncs a portion of the file.
Be aware that this is much-much slower than msyncing the whole file, even
if file is very large. The reason is that pager initiates asynchronous
_immediate_ clustered write for such situations. Async writes (AKA
bdwrite()) are only specified for full range msyncing.

>=20
> > Anyway, note that you cannot 'work with large files in memory', even if
> > you have enough RAM and no pressure to hold all the file pages resident.
> > The syncer will do a writeback periodically regardless of the applicati=
on
> > calling msync(2) or not, with the interval of approximately 30 seconds.
>=20
> You can mmap with MAP_NOSYNC to prevent the syncer from writing the file =
out
> every 30 seconds.

This also prevents msync(2) from syncing the region. The flag is fine
for throw-away data, but not for the scenario that was described, I
think.

--DI3e56nQDAJ1LWZd
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (FreeBSD)

iEYEARECAAYFAlCAMWoACgkQC3+MBN1Mb4iV7ACfeO+DqO2Onc8uMS29tjTbykJF
Ek0An1i+6oS2OaxLly9sI5pAGmKlXw8F
=UG69
-----END PGP SIGNATURE-----

--DI3e56nQDAJ1LWZd--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20121018164218.GR35915>