Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 2 Feb 2023 09:49:39 -0700
From:      Warner Losh <imp@bsdimp.com>
To:        Eugene Grosbein <eugen@grosbein.net>
Cc:        jbo@insane.engineer, "hackers@freebsd.org" <hackers@freebsd.org>
Subject:   Re: Swap, ZFS & ARC
Message-ID:  <CANCZdfqPHbfrhyhDEa-V%2BbPbV97UMyNSouMc6SaDCqVHB6NGiQ@mail.gmail.com>
In-Reply-To: <1689ba8c-a317-ce1f-2854-99566468a9ed@grosbein.net>
References:  <ysSGWaXF7vCDubzgFdov_9k6SMLNdZ3-zHV-2LOraYOxV_8yoAkDVPqDSicYsgBw1KdL6BjP4FkK1KFs7NKZ4RRXcSDxVe_Qy_i7b_5AbSI=@insane.engineer> <1689ba8c-a317-ce1f-2854-99566468a9ed@grosbein.net>

next in thread | previous in thread | raw e-mail | index | archive | help
--0000000000007c5f6d05f3ba5acf
Content-Type: text/plain; charset="UTF-8"

On Thu, Feb 2, 2023 at 7:42 AM Eugene Grosbein <eugen@grosbein.net> wrote:

> 02.02.2023 21:28, jbo@insane.engineer wrote:
> > Hello folks,
> >
> > Based on a discussion on the forums not so long ago I tried to figure
> out how swap usage on a ZFS system plays together with ARC. However, I
> could find very little to no information on this which leads me to believe
> that there is some "core concept" I might be oblivious to.
> >
> > The main question is basically this: Your system starts to swap out data
> from RAM to your swap partition.
> > This swap data on disk ultimately resides somewhere in a ZFS pool.
>
> I prefer not doing this. That is, all my systems have swap partition
> outside of ZFS pool.
>

I agree. Don't swap to anything but a raw partition if you have any way
possible to avoid it. Swapping to anything ZFS provides is a bad idea
because ZFS has to do memory allocations to do the I/O, which might not be
possible when heavily swapping on a memory constrained system. If it can't
allocate memory to do the swapping, it can't release the dirty memory that
is being swapped out, possibly leading to deadlock.

I actively avoid it unless there's no alternative, just like I actively
avoid swapping to a file in a filesystem like UFS if I can avoid it too...

Warner

--0000000000007c5f6d05f3ba5acf
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">On Thu, Feb 2, 2023 at 7:42 AM Eugene=
 Grosbein &lt;<a href=3D"mailto:eugen@grosbein.net">eugen@grosbein.net</a>&=
gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">02.02=
.2023 21:28, jbo@insane.engineer wrote:<br>
&gt; Hello folks,<br>
&gt; <br>
&gt; Based on a discussion on the forums not so long ago I tried to figure =
out how swap usage on a ZFS system plays together with ARC. However, I coul=
d find very little to no information on this which leads me to believe that=
 there is some &quot;core concept&quot; I might be oblivious to.<br>
&gt; <br>
&gt; The main question is basically this: Your system starts to swap out da=
ta from RAM to your swap partition.<br>
&gt; This swap data on disk ultimately resides somewhere in a ZFS pool.<br>
<br>
I prefer not doing this. That is, all my systems have swap partition outsid=
e of ZFS pool.<br></blockquote><div><br></div><div>I agree. Don&#39;t swap =
to anything but a raw partition if you have any way possible to avoid it. S=
wapping to anything ZFS provides is a bad idea because ZFS has to do memory=
 allocations to do the I/O, which might not be possible when heavily swappi=
ng on a memory constrained system. If it can&#39;t allocate memory to do th=
e swapping, it can&#39;t release the dirty memory that is being swapped out=
, possibly leading to deadlock.</div><div><br></div><div>I actively avoid i=
t unless there&#39;s no alternative, just like I actively avoid swapping to=
 a file in a filesystem like UFS if I can avoid it too...</div><div><br></d=
iv><div>Warner</div></div></div>

--0000000000007c5f6d05f3ba5acf--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfqPHbfrhyhDEa-V%2BbPbV97UMyNSouMc6SaDCqVHB6NGiQ>