From owner-freebsd-stable@FreeBSD.ORG Sun Feb 17 14:17:17 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 102F4E01; Sun, 17 Feb 2013 14:17:17 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13::5]) by mx1.freebsd.org (Postfix) with ESMTP id 859F799A; Sun, 17 Feb 2013 14:17:13 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.6/8.14.6) with ESMTP id r1HEH8LB030639; Sun, 17 Feb 2013 21:17:09 +0700 (NOVT) (envelope-from eugen@grosbein.net) Message-ID: <5120E65F.5080205@grosbein.net> Date: Sun, 17 Feb 2013 21:17:03 +0700 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.2.13) Gecko/20110112 Thunderbird/3.1.7 MIME-Version: 1.0 To: alc@freebsd.org Subject: Re: i386: vm.pmap kernel local race condition References: <511CECCC.60400@grosbein.pp.ru> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org, Alan Cox X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Feb 2013 14:17:17 -0000 17.02.2013 01:25, Alan Cox wrote: > Regardless of what that web site says, this is not really a race condition. Instead, you're exhausting a resource in the kernel because of the characteristics of your workload. The kernel tries to handle this gracefully, but in extreme cases, the kernel can't keep up with the demand. Have you simply tried doing as the panic message suggests, i.e., increase vm.pmap.shpgperproc? Alternatively, you can increase vm.pmap.pv_entry_max to more directly accomplish the same. > > That said, if possible, you should do as Adrian suggests and change your Squid configuration to not use 500 helper processes. That will allow a lot more of your machine's physical memory to go to caching data rather bookkeeping data structures in the kernel. A warning in src/sys/i386/conf/NOTES scares me: # # Set the number of PV entries per process. Increasing this can # stop panics related to heavy use of shared memory. However, that can # (combined with large amounts of physical memory) cause panics at # boot time due the kernel running out of VM space. # # If you're tweaking this, you might also want to increase the sysctls # "vm.v_free_min", "vm.v_free_reserved", and "vm.v_free_target". # # The value below is the one more than the default. # options PMAP_SHPGPERPROC=201 I guess, my 4G physical RAM is "large amount" for i386 so I'm afraid of remote server's kernel panic at boot time as I have no idea how exaclty should I increase value of vm.pmap.shpgperproc? What should be an increment? Using concurrency extension means moving from squid-3.1 to squid-3.2, I might try that too, thanks. I was not aware of this new feature in 3.2 Eugene Grosbein