Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 28 Jan 2020 17:42:06 +1100
From:      Peter Jeremy <peter@rulingia.com>
To:        Jeff Roberson <jroberson@jroberson.net>
Cc:        freebsd-arch@freebsd.org
Subject:   Re: Minimum memory for ZFS (was Re: svn commit: r356758 - in head/usr.sbin/bsdinstall: . scripts)
Message-ID:  <20200128064206.GC18006@server.rulingia.com>
In-Reply-To: <alpine.BSF.2.21.9999.2001261050070.1198@desktop>
References:  <202001230207.00N274xO042659@mail.karels.net> <alpine.BSF.2.21.9999.2001261050070.1198@desktop>

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

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

On 2020-Jan-26 10:58:15 -1000, Jeff Roberson <jroberson@jroberson.net> wrot=
e:
>My proposal is this, limit ARC to some reasonable fraction of memory, say=
=20
>1/8th, and then do the following:
>
>On expiration from arc place the pages in a vm object associated with the=
=20
>device.  The VM is now free to keep them or re-use them for user memory.
>
>On miss from arc check the page cache and take the pages back if they=20
>exist.
>
>On invalidation you need to invalidate the page cache.

ZFS already has a mechanism for the VM system to request that ARC be
shrunk.  This was designed around the Solaris VM system and isn't a perfect
match with the FreeBSD VM system.  There has been a lot of work, within
FreeBSD, over the years to improve the way this behaves but it's obviously
not perfect.  One point of confusion is that FreeBSD and Solaris use
identical terms to mean different things within their VM systems.

>ARC already allows spilling to SSD.  I don't know the particulars of the=
=20
>interface but we're essentially spilling to memory that can be reclaimed=
=20
>by the page daemon as necessary.

This is L2ARC.  ZFS expects that L2ARC refers to a fixed amount of space
that ZFS has control over.  I'm unaware of any mechanism for an external
system to reclaim L2ARC space - it would require the external system to
request ZFS (via an, AFAIK, non-existent interface) to free L2ARC objects.

ZFS only implements a single level of L2ARC so re-using L2ARC for this new
caching mechanism would also prevent the use of traditional SSD-based L2ARC
on FreeBSD.

Since ZFS already has a mechanism for an external system to request that
ZFS release memory, I believe effort would be better expended in getting
FreeBSD to better exchange memory pressure data with ZFS via that existing
mechanism, rather than inventing a new mechanism that is intended to
achieve much the same result, whilst effectively removing a ZFS feature.

--=20
Peter Jeremy

--3lcZGd9BuhuYXNfi
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQKTBAEBCgB9FiEE7rKYbDBnHnTmXCJ+FqWXoOSiCzQFAl4v17RfFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEVF
QjI5ODZDMzA2NzFFNzRFNjVDMjI3RTE2QTU5N0EwRTRBMjBCMzQACgkQFqWXoOSi
CzSimA//fWxhdJoFxJPRKrBiJbiw214dpxYRQCufg+9XDuMIqIC19ks5WUXjyY8G
cv/jmCCS96DpJFlccZZZu6SlUFkthAFkc2PDHXBWQSdwJ/c6FSMkxmwG2LChuW9U
ElX8Y7Aoe0EjoC9yDh0bQWNjwlTL0mZCFvf9veeFVhZ7b3agE7ZMiAvU4kdY2QfC
gt7eWDXUNSVKv4egK1T0qW50jBCiQn3kd9siAWiszVY1ncQ3YqN8mLaC6PmfGo4J
jg85K53yEGY8IdtBS8ggQsvNPn0CNw7obEAMPdsqwBEZHzgqsed27PtYNSS4zRun
lMmk0sBi3GBJeZYT7dY6JpW9wnoM044fBbcwPUNZM4ApWKvvQ8r8xSgf/tb12cdr
ywjTdNeoTTP4CZNxzonEfZ0jadnVIMY6R+sjB0AXpX04WLg91MwqHoVqX3kN6plG
23xA79ZA613qDgeU/B1KB63wP6oAvQn9b0AmgHglAlzOipxIXyclacu9lMpRvbGq
vNKaaQYtNrB5guzdo13uad4SGmKp7tsa3vMzmwpIpoCgP1uU5DMBPvkWTqkjEtTA
IYEygSWhYrY+XrhHgyI5HBU9B5IgSD4lDP88jCiFEigy8mbtMgDBOyxx/Ed8Ctj9
LjIDO/41qGs1vQpxVNI4BIAf3YKwfnuxd53cFAsxIT0rI/6rq00=
=g7Ct
-----END PGP SIGNATURE-----

--3lcZGd9BuhuYXNfi--



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