Date: Sun, 17 Feb 2013 19:54:23 -0600 From: Alan Cox <alc@rice.edu> To: Eugene Grosbein <eugen@grosbein.net> Cc: alc@freebsd.org, stable@freebsd.org, Alan Cox <alan.l.cox@gmail.com> Subject: Re: i386: vm.pmap kernel local race condition Message-ID: <512189CF.4080204@rice.edu> In-Reply-To: <5120E65F.5080205@grosbein.net> References: <511CECCC.60400@grosbein.pp.ru> <CAJUyCcOHFgGqzvm43y-dojvsXdNydYmfd9rwHMkdjqDyvjJuKQ@mail.gmail.com> <5120E65F.5080205@grosbein.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 02/17/2013 08:17, Eugene Grosbein wrote: > 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? Run "sysctl vm.kvm_free" and "sysctl vm.pmap.pv_entry_max". The former sysctl tells you how many bytes of free kernel address space that you have. Basically, you want to ensure that this number doesn't go to zero. Every pv entry occupies 12 bytes. To start with, my suggestion would be to increase the maximum number of pv entries until it consumes about half of your current free kernel address space. Once you've decided on a new maximum value that you want to try, set the tunable "vm.pmap.pv_entries" in /boot/loader.conf. Ignore the other comments from NOTES. > 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 >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?512189CF.4080204>