On Sat, 6 Mar 2004, Vincent Poy wrote: > On Fri, 5 Mar 2004, Jon Noack wrote: > > > On 3/5/2004 6:23 AM, Vincent Poy wrote: > > > On Fri, 5 Mar 2004, Jon Noack wrote: > > >> On 3/4/2004 4:13 PM, Vincent Poy wrote: > > >>> On Thu, 4 Mar 2004, Andrew Gallatin wrote: > > >>>> Vincent Poy writes: > > >>>>> Interesting. I'm still wondering what the VM_KMEM_SIZE_SCALE > > >>>>> number represents. > > >>>> > > >>>> It tries to autoscale the kmem size, so that you don't need to hard > > >>>> code it. Hardcoding it could be bad if you change the amount of ram > > >>>> in the box. > > >>> > > >>> That part I understand but what exactly does the number 2 and 3 > > >>> mean? > > >> > > >> VM_KMEM_SIZE_SCALE: > > >> How many physical pages per KVA page allocated. > > >> > > >> <snip> > > > > > > I actually read that part already but is 2 basically 1/2 and 3 > > > actually just 1/3? > > > > That's the way I read it -- check out this comment again (from > > src/sys/i386/include/vmparam.h -- hopefully the formatting will be ok): > > > /* > > > * How many physical pages per KVA page allocated. > > > * min(max(VM_KMEM_SIZE, Physical memory/VM_KMEM_SIZE_SCALE), > > VM_KMEM_SIZE_MAX) > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > * is the total KVA space allocated for kmem_map. > > > */ > > > > VM_KMEM_SIZE_SCALE is used to autoscale the value in this range: > > VM_KMEM_SIZE <= vm_kmem_size <= VM_KMEM_SIZE_MAX > > > > This ensures we have a reasonable minimum (VM_KMEM_SIZE) and maximum > > (VM_KMEM_SIZE_MAX) while making a fair effort at efficiently utilizing > > available memory (Physical memory/VM_KMEM_SIZE_SCALE). > > Thanks. So it's easier to understand now. I'm getting the > following panic only when I run the following script after like a few > hours of uptime but works fine if I do it within 30 minutes of uptime... > /sbin/mount /dev/ad2s1a /mnt/root > /sbin/mount /dev/ad2s1d /mnt/usr > killall -9 sendmail > cd /mnt/root > /bin/chflags -R noschg . > /bin/rm -rf .* > /bin/rm -rf * > /sbin/dump -L -f- /|restore -rf- > cd /mnt/usr > /bin/chflags -R noschg . > /bin/rm -rf .* > /bin/rm -rf * > /sbin/dump -L -f- /usr|restore -rf- > /usr/sbin/sendmail -L sm-mta -bd -q1m > /usr/sbin/sendmail -L sm-queue -q1m > /usr/sbin/sendmail -L sm-msp-queue -Ac -q1m > /usr/sbin/sendmail -L sm-mta-submit -bd -q1m > -ODaemonPortOptions=Addr=localhost > > panic: kmem_malloc (4096): kmem_map too small: 377487360 total allocated > at line 341 in file /usr/src/sys/vm/vm_kern.c > cpuid=0; > Debugger("panic") > Stopped at Debugger+0x46: xchgl %ebx, in_Debugger.0 > > It seems to do it on the dump of /usr and restoring to /mnt/usr. > I have tried the following but they panic the kernel as soon as the memory > size is displayed. > > added to kernel config: > options VM_KMEM_SIZE_MAX=(768*1048576) > options VM_KMEM_SIZE_SCALE=2 > > Tried it on a kernel without the above but added in /boot/loader.conf > > vm.kmem_size=429391872 > > and they both crashed at the same spot as well... > > CPU: Mobile Intel(R) Pentium(R) 4 - M CPU 2.60GHz (2592.36-MHz 686-class CPU) > Origin = "GenuineIntel" Id = 0xf29 Stepping = 9 > > Features=0xbfebf9ff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,P > AT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE> > real memory = 2147360768 (2047 MB) > avail memory = 2095669248 (1998 MB) > > Any ideas how to fix this? I managed to get the system not panicing on bootup if I set the VM_KMEM_SIZE_MAX to 384MB. At 512MB and 768MB, it would panic but anyone knows what the default VM_KMEM_SIZE_MAX size is? Cheers, Vince - vince_at_WURLDLINK.NET - Vice President ________ __ ____ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] WurldLink Corporation / / / / | / | __] ] San Francisco - Honolulu - Hong Kong / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[____] Almighty1_at_IRC - oahu.DAL.NET Hawaii's DALnet IRC Network Server AdminReceived on Sat Mar 06 2004 - 21:47:36 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:46 UTC