Date: Tue, 28 Sep 2010 11:50:05 -0400 From: Ben Kelly <ben@wanderview.com> To: Andriy Gapon <avg@icyb.net.ua> Cc: stable@freebsd.org, Willem Jan Withagen <wjw@digiware.nl>, fs@freebsd.org, Jeremy Chadwick <freebsd@jdc.parodius.com> Subject: Re: Still getting kmem exhausted panic Message-ID: <FE116FEC-714D-4BF5-86D8-E29BFA713C69@wanderview.com> In-Reply-To: <4CA1EF69.4040402@icyb.net.ua> References: <4CA1D06C.9050305@digiware.nl> <20100928115047.GA62142__15392.0458550148$1285675457$gmane$org@icarus.home.lan> <4CA1DDE9.8090107@icyb.net.ua> <20100928132355.GA63149@icarus.home.lan> <4CA1EF69.4040402@icyb.net.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sep 28, 2010, at 9:36 AM, Andriy Gapon wrote: > Well, no time for me to dig through all that history. > arc_max should be a hard limit and it is now. If it ever wasn't then = it was a bug. I believe the size of the arc could exceed the limit if your working set = was larger than arc_max. The arc can't (couldn't then, anyway) evict = data that is still referenced. A contributing factor at the time was that the page daemon did not take = into account back pressure from the arc when deciding which pages to = move from active to inactive, etc. So data was more likely to be = referenced and therefore forced to remain in the arc. I'm not sure if this is still the current state. I seem to remember = some changesets mentioning arc back pressure at some point, but I don't = know the details. - Ben=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?FE116FEC-714D-4BF5-86D8-E29BFA713C69>