tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: more on the "vmmapva" kernel deadlocks on NetBSD-4

At Sun, 21 Jun 2009 13:32:02 -0400, "Greg A. Woods" 
<> wrote:
Subject: Re: more on the "vmmapva" kernel deadlocks on NetBSD-4
> Well, if it means anything my server lived through the night without any
> problems after rebooting with the BUFCACHE=5 kernel.

And 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.

> Now to do some debugging and find out what the numbers actually are to
> see if I can code some reasonable heuristic for limiting BUFCACHE at
> boot automatically.

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

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:

>> NetBSD/i386 BIOS Boot, Revision 3.3
>> (woods@once, Tue Jun 16 17:57:15 EDT 2009)
>> Memory: 617/2094976 k
Press return to boot now, any other key for boot menu
booting hd0a:netbsd - starting in 0 
9381768+411940+376076 [443616+426273]=0xa88fd8
initial mem_cluster_cnt: 0
    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=376
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
total memory = 2046 MB
rbus: rbus_min_start set to 0x80000000
avail memory = 1988 MB
buf_memcalc: bufcache is preset to 5%
buf_memcalc: bufmem calculated to be to 107274240 bytes
nbuf (bufhashtbl size) = 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)

                                                Greg A. Woods
                                                Planix, Inc.

<>       +1 416 218-0099

Attachment: pgpmNr5ULjUuh.pgp
Description: PGP signature

Home | Main Index | Thread Index | Old Index