Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 20 Mar 2014 17:06:07 +0200
From:      Andriy Gapon <avg@FreeBSD.org>
To:        Karl Denninger <karl@denninger.net>, freebsd-fs@FreeBSD.org
Subject:   Re: kern/187594: [zfs] [patch] ZFS ARC behavior problem and fix
Message-ID:  <532B03DF.7080503@FreeBSD.org>
In-Reply-To: <201403201230.s2KCU1vx057435@freefall.freebsd.org>
References:  <201403201230.s2KCU1vx057435@freefall.freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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@denninger.net>
> To: bug-followup@FreeBSD.org, karl@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



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