kern/187594: [zfs] [patch] ZFS ARC behavior problem and fix

Andriy Gapon avg at FreeBSD.org
Thu Mar 20 15:06:52 UTC 2014


on 20/03/2014 14:30 Karl Denninger said the following:
> The following reply was made to PR kern/187594; it has been noted by GNATS.
> 
> From: Karl Denninger <karl at denninger.net>
> To: bug-followup at FreeBSD.org, karl at fs.denninger.net
> Cc:  
> Subject: Re: kern/187594: [zfs] [patch] ZFS ARC behavior problem and fix
> Date: Thu, 20 Mar 2014 07:26:39 -0500
> 
>  This is a cryptographically signed message in MIME format.
>  
>  --------------ms010203060907010901070002
>  Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>  Content-Transfer-Encoding: quoted-printable
>  
>  I am increasingly-convinced with increasing runtime now on both=20
>  synthetic and real loads in production that the proper default value for =
>  
>  vfs.zfs.arc_freepages is vm.stats.vm.v_free_target less "just a bit." =20
>  Five percent appears to be ok for most workloads with RAM configurations =

How about just changing vm_paging_needed() check to vm_paging_target() > 0
check?  Could you please try to test this?

>  ranging from 4GB to the 24GB area (configurations that I can easily test =
>  
>  under both synthetic and real environments.)
>  
>  Larger invasions of the free target increasingly risk provocation of the =
>  
>  behavior that prompted me to get involved in working this part of the=20
>  code in the first place, including short-term (~5-10 second) "stalls"=20
>  during which the system appears to be locked up, but is not.
>  
>  It appears that the key to avoiding that behavior is to not allow the=20
>  ARC to continue to take RAM when a material invasion of that target=20
>  space has occurred.


-- 
Andriy Gapon


More information about the freebsd-fs mailing list