At Sun, 21 Jun 2009 13:32:02 -0400, "Greg A. Woods" <woods@planix.com> wrot= e: Subject: Re: more on the "vmmapva" kernel deadlocks on NetBSD-4And now it's still chugging along happily: $ uptime 4:34PM up 13 days, 4:11, 7 users, load averages: 0.14, 0.11, 0.37 I'm obviously not seeing quite as much "pages for cached file data" in "systat buf" (rarely more than 70%), so a fair bit of RAM is being wasted under the normal load profiles of this system, usually ~120MB but that's not too bad on a system with 4GB I suppose, and it certainly leaves lots of room for peak loads without needing any paging. The coded I added to sys/i386/i386/pmap.c:pmap_bootstrap() does not work because the code it calls (vfs_bio.c:buf_memcalc()) relies on the global value of physmem to do its initial calculation. Unfortunately on i386 it seems physmem isn't set soon enough. It is set within the call to init386() in locore.S. init386() also calls pmap_bootstrap(), but it does so before it calculates physmem. I'm not sure if this can be reordered safely or not -- it seems that other ports, notably alpha, mips, vax, and ia64 (though I'm not 100% sure about mips), do calculate physmem before calling their pmap_bootstrap(). So, as a test I moved the call to pmap_bootstrap() down below the physmem calculations (I can't see any obvious interdependency that would require the old order, turned on DEBUG_MEMLOAD for a wee extra peek into things, and so far my test machine boots and runs just fine: Press return to boot now, any other key for boot menu booting hd0a:netbsd - starting in 0=20 9381768+411940+376076 [443616+426273]=3D0xa88fd8 initial mem_cluster_cnt: 0 BIOS MEMORY MAP (8 ENTRIES): addr 0x0 size 0x9a400 type 0x1 addr 0xf0000 size 0x10000 type 0x2 addr 0xfec00000 size 0x1400000 type 0x2 addr 0x7fee3000 size 0xd000 type 0x3 addr 0x7fee0000 size 0x3000 type 0x4 addr 0x9a400 size 0x5c00 type 0x2 addr 0x7fef0000 size 0x10000 type 0x2 addr 0x100000 size 0x7fde0000 type 0x1 final mem_cluster_cnt: 2 KVA space seems to be: 1057026048 buf_memcalc: bufcache is preset to 5% buf_memcalc: bufmem calculated to be to 107274240 bytes loading 0x7000-0x9a000 (0x7-0x9a) loading 0xb91000-0x1000000 (0xb91-0x1000) loading 0x1000000-0x7fee0000 (0x1000-0x7fee0) kenter: 0x00002000 acpi: wakecode is installed at 0x2000, size=3D376 Loaded initial symtab at 0xc0ab4630, strtab at 0xc0b20eb4, # entries 26187 BIOS CFG: Model-SubM-Rev: fc-01-00, 0x74<EBDA,KBDINT,RTC,IC2> Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007 The NetBSD Foundation, Inc. All rights reserved. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. NetBSD 4.0_STABLE (GENERIC.MP) #10: Fri Jul 3 16:14:15 EDT 2009 woods@once:/rest/build/woods/once/netbsd-4-i386-i386-ppro-obj/rest/= work/woods/m-NetBSD-4/sys/arch/i386/compile/GENERIC.MP total memory =3D 2046 MB rbus: rbus_min_start set to 0x80000000 avail memory =3D 1988 MB buf_memcalc: bufcache is preset to 5% buf_memcalc: bufmem calculated to be to 107274240 bytes nbuf (bufhashtbl size) =3D 34920 Now maybe I should try this on the 4GB machine.... with bufcache set back up to a higher number and then I can see if I can find some more appropriate values to use for smarter auto-tuning.... (Maybe the copyright and build info prints should be moved up a bit too) --=20 Greg A. Woods Planix, Inc. <woods@planix.com> +1 416 218-0099 http://www.planix.com/
| Amit K. Arora | [RFC] Heads up on sys_fallocate() |
| H. Peter Anvin | Re: [RFC 00/15] x86_64: Optimize percpu accesses |
| Nicolas Pitre | Re: [RFC patch 08/18] cnt32_to_63 should use smp_rmb() |
| Bart Van Assche | Integration of SCST in the mainstream Linux kernel |
git: | |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| David Miller | [GIT]: Networking |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
| Natalie Protasevich | [BUG] New Kernel Bugs |
