Utilisation of free memory as disc cache: tweaking is required?

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Utilisation of free memory as disc cache: tweaking is required?

Constantine A. Murenin
Hello,

I have a box with 512MB of RAM, which is running a snapshot from 2006-02-13.

The box does not get used much, so most of the RAM stays still, i.e.
not used by the userland.

I am now quite surprised why OpenBSD does not use all of this RAM for
disc cache etc.


After rebooting the system, I took some measurements from the root
console (where only one other user was logged in, who ran a `top`
every once in a while).

In the fragment of my session below, you can see that running
identical `find /usr/src/sys/ -name "*.[ch]" | xargs grep qwertyuiop`
command does not seem to utilise any disc cache before the kernel
option gets modified. After we increase kern.maxvnodes by a factor of
16, we immediately get huge benefits of running identical 'find ..
grep ..' command the second time etc.


Before tweaking kern.maxvnodes:
        free memory after 'find .. grep ..' is around 368MB
        repeated 'find .. grep ..' always take as much as 14 seconds

After tweaking kern.maxvnodes:
        free memory after 'find .. grep ..' is around 338MB
        repeated 'find .. grep ..' take as little as 3,9 seconds


My question is thus:
        Is there a reason no algorithm is used to automatically modify kernel
variables such as kern.maxvnodes to efficiently account free memory
for disc cache?


Here is the session log:


tvc# idate
2006-02-18T13:36:22Z
tvc# sysctl kern
kern.ostype=OpenBSD
kern.osrelease=3.9
kern.osrevision=200605
kern.version=OpenBSD 3.9-beta (GENERIC) #601: Sun Feb 12 21:39:52 MST 2006
    [hidden email]:/usr/src/sys/arch/i386/compile/GENERIC

kern.maxvnodes=1310
kern.maxproc=532
kern.maxfiles=1772
kern.argmax=262144
kern.securelevel=1
kern.hostname=tvc.home.const.name
kern.hostid=0
kern.clockrate=tick = 10000, tickadj = 40, hz = 100, profhz = 1024, stathz = 128
kern.posix1version=199009
kern.ngroups=16
kern.job_control=1
kern.saved_ids=1
kern.boottime=Sat Feb 18 13:33:45 2006
kern.domainname=
kern.maxpartitions=16
kern.rawpartition=2
kern.osversion=GENERIC#601
kern.somaxconn=128
kern.sominconn=80
kern.usermount=0
kern.random=29769 533248 0 28232 5 1032 0 0 0 0 0 0 10775 8441 0 23
8411 1 7 18 35 71 104 156 211 220 218 114 121 114 78 62 95 90 134 155
185 117 45 4 3 1 0 0 0 3 2 0 0 8408 0 81 1335 951 0 0 0 0 0 1369 12780
16079 0 0
kern.nosuidcoredump=1
kern.fsync=1
kern.sysvmsg=1
kern.sysvsem=1
kern.sysvshm=1
kern.arandom=151420742
kern.msgbufsize=16364
kern.malloc.buckets=16,32,64,128,256,512,1024,2048,4096,8192,16384,32768,65536,131072,262144,524288
kern.malloc.bucket.16=(calls = 25540 total_allocated = 3584 total_free
= 743 elements = 256 high watermark = 1280 could_free = 0)
kern.malloc.bucket.32=(calls = 4861 total_allocated = 1280 total_free
= 145 elements = 128 high watermark = 640 could_free = 0)
kern.malloc.bucket.64=(calls = 2479 total_allocated = 640 total_free =
90 elements = 64 high watermark = 320 could_free = 0)
kern.malloc.bucket.128=(calls = 881 total_allocated = 320 total_free =
41 elements = 32 high watermark = 160 could_free = 0)
kern.malloc.bucket.256=(calls = 615 total_allocated = 192 total_free =
12 elements = 16 high watermark = 80 could_free = 0)
kern.malloc.bucket.512=(calls = 382 total_allocated = 112 total_free =
13 elements = 8 high watermark = 40 could_free = 0)
kern.malloc.bucket.1024=(calls = 1247 total_allocated = 232 total_free
= 4 elements = 4 high watermark = 20 could_free = 0)
kern.malloc.bucket.2048=(calls = 102 total_allocated = 92 total_free =
1 elements = 2 high watermark = 10 could_free = 0)
kern.malloc.bucket.4096=(calls = 229 total_allocated = 33 total_free =
1 elements = 1 high watermark = 5 could_free = 0)
kern.malloc.bucket.8192=(calls = 10 total_allocated = 10 total_free =
0 elements = 1 high watermark = 5 could_free = 0)
kern.malloc.bucket.16384=(calls = 1 total_allocated = 1 total_free = 0
elements = 1 high watermark = 5 could_free = 0)
kern.malloc.bucket.32768=(calls = 1 total_allocated = 1 total_free = 0
elements = 1 high watermark = 5 could_free = 0)
kern.malloc.bucket.65536=(calls = 2 total_allocated = 2 total_free = 0
elements = 1 high watermark = 5 could_free = 0)
kern.malloc.bucket.131072=(calls = 0 total_allocated = 0 total_free =
0 elements = 1 high watermark = 5 could_free = 0)
kern.malloc.bucket.262144=(calls = 0 total_allocated = 0 total_free =
0 elements = 1 high watermark = 5 could_free = 0)
kern.malloc.bucket.524288=(calls = 0 total_allocated = 0 total_free =
0 elements = 1 high watermark = 5 could_free = 0)
kern.malloc.kmemnames=free,mbuf,devbuf,debug,pcb,routetbl,,fragtbl,,ifaddr,soopts,sysctl,,,ioctlops,,,,,iov,mount,,NFS_req,NFS_mount,NFS_node,vnodes,namecache,UFS_quota,UFS_mount,shm,VM_map,sem,dirhash,,VM_pmap,,,,file,file_desc,,proc,subproc,VFS_cluster,,,MFS_node,,,Export_Host,NFS_srvsock,NFS_uid,NFS_daemon,ip_moptions,in_multi,ether_multi,mrt,ISOFS_mount,ISOFS_node,MSDOSFS_mount,MSDOSFS_fat,MSDOSFS_node,ttys,exec,miscfs_mount,,adosfs_mount,,adosfs_anode,,,adosfs_bitmap,,,pfkey_data,tdb,xform_data,,pagedep,inodedep,newblk,,,indirdep,,,,,,,,,VM_swap,,,,,RAIDframe_data,UVM_amap,UVM_aobj,,USB,USB_device,USB_HC,,memdesc,,,crypto_data,,IPsec_creds,packet_tags,1394ctl,1394data,emuldata,,,,,,,,,ip6_options,NDP,ip6rr,rp_addr,temp,NTFS_mount,NTFS_node,NTFS_fnode,NTFS_dir,NTFS_hash_tables,NTFS_file_attr,NTFS_resident_data_,NTFS_decomp,NTFS_vrun,kqueue,bluetooth,bwmeter,UDF_mount,UDF_file_entry,UDF_file_id
kern.malloc.kmemstat.free=(inuse = 0, calls = 0, memuse = 0K,
limblocks = 0, mapblocks = 0, maxused = 0K, limit = 39322K, spare = 0,
sizes = (none))
kern.malloc.kmemstat.mbuf=(inuse = 0, calls = 0, memuse = 0K,
limblocks = 0, mapblocks = 0, maxused = 0K, limit = 39322K, spare = 0,
sizes = (none))
kern.malloc.kmemstat.devbuf=(inuse = 661, calls = 719, memuse = 300K,
limblocks = 0, mapblocks = 0, maxused = 300K, limit = 39322K, spare =
0, sizes = (16,32,64,128,256,512,1024,2048,4096,8192,16384))
kern.malloc.kmemstat.debug=(inuse = 0, calls = 0, memuse = 0K,
limblocks = 0, mapblocks = 0, maxused = 0K, limit = 39322K, spare = 0,
sizes = (none))
kern.malloc.kmemstat.pcb=(inuse = 19, calls = 63, memuse = 3K,
limblocks = 0, mapblocks = 0, maxused = 3K, limit = 39322K, spare = 0,
sizes = (16,32,64,512))
kern.malloc.kmemstat.routetbl=(inuse = 57, calls = 80, memuse = 5K,
limblocks = 0, mapblocks = 0, maxused = 5K, limit = 39322K, spare = 0,
sizes = (16,32,64,128,256))
kern.malloc.kmemstat.fragtbl=(inuse = 0, calls = 1, memuse = 0K,
limblocks = 0, mapblocks = 0, maxused = 1K, limit = 39322K, spare = 0,
sizes = (32))
kern.malloc.kmemstat.ifaddr=(inuse = 42, calls = 42, memuse = 10K,
limblocks = 0, mapblocks = 0, maxused = 10K, limit = 39322K, spare =
0, sizes = (16,32,128,256,512,2048))
kern.malloc.kmemstat.soopts=(inuse = 0, calls = 0, memuse = 0K,
limblocks = 0, mapblocks = 0, maxused = 0K, limit = 39322K, spare = 0,
sizes = (none))
kern.malloc.kmemstat.sysctl=(inuse = 3, calls = 3, memuse = 3K,
limblocks = 0, mapblocks = 0, maxused = 3K, limit = 39322K, spare = 0,
sizes = (16,256,2048))
kern.malloc.kmemstat.ioctlops=(inuse = 0, calls = 46, memuse = 0K,
limblocks = 0, mapblocks = 0, maxused = 2K, limit = 39322K, spare = 0,
sizes = (512,1024,2048))
kern.malloc.kmemstat.iov=(inuse = 0, calls = 0, memuse = 0K, limblocks
= 0, mapblocks = 0, maxused = 0K, limit = 39322K, spare = 0, sizes =
(none))
kern.malloc.kmemstat.mount=(inuse = 14, calls = 16, memuse = 7K,
limblocks = 0, mapblocks = 0, maxused = 8K, limit = 39322K, spare = 0,
sizes = (512))
kern.malloc.kmemstat.NFS_req=(inuse = 0, calls = 0, memuse = 0K,
limblocks = 0, mapblocks = 0, maxused = 0K, limit = 39322K, spare = 0,
sizes = (none))
kern.malloc.kmemstat.NFS_mount=(inuse = 0, calls = 0, memuse = 0K,
limblocks = 0, mapblocks = 0, maxused = 0K, limit = 39322K, spare = 0,
sizes = (none))
kern.malloc.kmemstat.NFS_node=(inuse = 1, calls = 1, memuse = 8K,
limblocks = 0, mapblocks = 0, maxused = 8K, limit = 39322K, spare = 0,
sizes = (8192))
kern.malloc.kmemstat.vnodes=(inuse = 1029, calls = 1270, memuse = 38K,
limblocks = 0, mapblocks = 0, maxused = 43K, limit = 39322K, spare =
0, sizes = (32,128,256))
kern.malloc.kmemstat.namecache=(inuse = 3, calls = 3, memuse = 41K,
limblocks = 0, mapblocks = 0, maxused = 41K, limit = 39322K, spare =
0, sizes = (1024,8192,32768))
kern.malloc.kmemstat.UFS_quota=(inuse = 1, calls = 1, memuse = 8K,
limblocks = 0, mapblocks = 0, maxused = 8K, limit = 39322K, spare = 0,
sizes = (8192))
kern.malloc.kmemstat.UFS_mount=(inuse = 57, calls = 57, memuse = 104K,
limblocks = 0, mapblocks = 0, maxused = 104K, limit = 39322K, spare =
0, sizes = (16,32,64,256,512,2048,4096,8192))
kern.malloc.kmemstat.shm=(inuse = 2, calls = 2, memuse = 1K, limblocks
= 0, mapblocks = 0, maxused = 1K, limit = 39322K, spare = 0, sizes =
(256,512))
kern.malloc.kmemstat.VM_map=(inuse = 3, calls = 3, memuse = 1K,
limblocks = 0, mapblocks = 0, maxused = 1K, limit = 39322K, spare = 0,
sizes = (256))
kern.malloc.kmemstat.sem=(inuse = 2, calls = 2, memuse = 1K, limblocks
= 0, mapblocks = 0, maxused = 1K, limit = 39322K, spare = 0, sizes =
(32,64))
kern.malloc.kmemstat.dirhash=(inuse = 27, calls = 27, memuse = 5K,
limblocks = 0, mapblocks = 0, maxused = 5K, limit = 39322K, spare = 0,
sizes = (16,32,64,512))
kern.malloc.kmemstat.VM_pmap=(inuse = 0, calls = 0, memuse = 0K,
limblocks = 0, mapblocks = 0, maxused = 0K, limit = 39322K, spare = 0,
sizes = (none))
kern.malloc.kmemstat.file=(inuse = 0, calls = 0, memuse = 0K,
limblocks = 0, mapblocks = 0, maxused = 0K, limit = 39322K, spare = 0,
sizes = (none))
kern.malloc.kmemstat.file_desc=(inuse = 0, calls = 0, memuse = 0K,
limblocks = 0, mapblocks = 0, maxused = 0K, limit = 39322K, spare = 0,
sizes = (none))
kern.malloc.kmemstat.proc=(inuse = 8, calls = 8, memuse = 3K,
limblocks = 0, mapblocks = 0, maxused = 3K, limit = 39322K, spare = 0,
sizes = (32,256,1024))
kern.malloc.kmemstat.subproc=(inuse = 0, calls = 0, memuse = 0K,
limblocks = 0, mapblocks = 0, maxused = 0K, limit = 39322K, spare = 0,
sizes = (none))
kern.malloc.kmemstat.VFS_cluster=(inuse = 0, calls = 61, memuse = 0K,
limblocks = 0, mapblocks = 0, maxused = 1K, limit = 39322K, spare = 0,
sizes = (32))
kern.malloc.kmemstat.MFS_node=(inuse = 0, calls = 0, memuse = 0K,
limblocks = 0, mapblocks = 0, maxused = 0K, limit = 39322K, spare = 0,
sizes = (none))
kern.malloc.kmemstat.Export_Host=(inuse = 0, calls = 0, memuse = 0K,
limblocks = 0, mapblocks = 0, maxused = 0K, limit = 39322K, spare = 0,
sizes = (none))
kern.malloc.kmemstat.NFS_srvsock=(inuse = 2, calls = 2, memuse = 1K,
limblocks = 0, mapblocks = 0, maxused = 1K, limit = 39322K, spare = 0,
sizes = (256))
kern.malloc.kmemstat.NFS_uid=(inuse = 0, calls = 0, memuse = 0K,
limblocks = 0, mapblocks = 0, maxused = 0K, limit = 39322K, spare = 0,
sizes = (none))
kern.malloc.kmemstat.NFS_daemon=(inuse = 1, calls = 1, memuse = 1K,
limblocks = 0, mapblocks = 0, maxused = 1K, limit = 39322K, spare = 0,
sizes = (256))
kern.malloc.kmemstat.ip_moptions=(inuse = 0, calls = 0, memuse = 0K,
limblocks = 0, mapblocks = 0, maxused = 0K, limit = 39322K, spare = 0,
sizes = (none))
kern.malloc.kmemstat.in_multi=(inuse = 22, calls = 22, memuse = 1K,
limblocks = 0, mapblocks = 0, maxused = 1K, limit = 39322K, spare = 0,
sizes = (16,64))
kern.malloc.kmemstat.ether_multi=(inuse = 4, calls = 4, memuse = 1K,
limblocks = 0, mapblocks = 0, maxused = 1K, limit = 39322K, spare = 0,
sizes = (32))
kern.malloc.kmemstat.mrt=(inuse = 0, calls = 0, memuse = 0K, limblocks
= 0, mapblocks = 0, maxused = 0K, limit = 39322K, spare = 0, sizes =
(none))
kern.malloc.kmemstat.ISOFS_mount=(inuse = 1, calls = 1, memuse = 8K,
limblocks = 0, mapblocks = 0, maxused = 8K, limit = 39322K, spare = 0,
sizes = (8192))
kern.malloc.kmemstat.ISOFS_node=(inuse = 0, calls = 0, memuse = 0K,
limblocks = 0, mapblocks = 0, maxused = 0K, limit = 39322K, spare = 0,
sizes = (none))
kern.malloc.kmemstat.MSDOSFS_mount=(inuse = 1, calls = 1, memuse = 4K,
limblocks = 0, mapblocks = 0, maxused = 4K, limit = 39322K, spare = 0,
sizes = (4096))
kern.malloc.kmemstat.MSDOSFS_fat=(inuse = 0, calls = 0, memuse = 0K,
limblocks = 0, mapblocks = 0, maxused = 0K, limit = 39322K, spare = 0,
sizes = (none))
kern.malloc.kmemstat.MSDOSFS_node=(inuse = 0, calls = 0, memuse = 0K,
limblocks = 0, mapblocks = 0, maxused = 0K, limit = 39322K, spare = 0,
sizes = (none))
kern.malloc.kmemstat.ttys=(inuse = 414, calls = 414, memuse = 242K,
limblocks = 0, mapblocks = 0, maxused = 242K, limit = 39322K, spare =
0, sizes = (128,256,1024))
kern.malloc.kmemstat.exec=(inuse = 0, calls = 224, memuse = 0K,
limblocks = 0, mapblocks = 0, maxused = 2K, limit = 39322K, spare = 0,
sizes = (16,128,512,1024))
kern.malloc.kmemstat.miscfs_mount=(inuse = 0, calls = 0, memuse = 0K,
limblocks = 0, mapblocks = 0, maxused = 0K, limit = 39322K, spare = 0,
sizes = (none))
kern.malloc.kmemstat.adosfs_mount=(inuse = 0, calls = 0, memuse = 0K,
limblocks = 0, mapblocks = 0, maxused = 0K, limit = 39322K, spare = 0,
sizes = (none))
kern.malloc.kmemstat.adosfs_anode=(inuse = 0, calls = 0, memuse = 0K,
limblocks = 0, mapblocks = 0, maxused = 0K, limit = 39322K, spare = 0,
sizes = (none))
kern.malloc.kmemstat.adosfs_bitmap=(inuse = 0, calls = 0, memuse = 0K,
limblocks = 0, mapblocks = 0, maxused = 0K, limit = 39322K, spare = 0,
sizes = (none))
kern.malloc.kmemstat.pfkey_data=(inuse = 1, calls = 2, memuse = 1K,
limblocks = 0, mapblocks = 0, maxused = 1K, limit = 39322K, spare = 0,
sizes = (64))
kern.malloc.kmemstat.tdb=(inuse = 0, calls = 0, memuse = 0K, limblocks
= 0, mapblocks = 0, maxused = 0K, limit = 39322K, spare = 0, sizes =
(none))
kern.malloc.kmemstat.xform_data=(inuse = 0, calls = 18, memuse = 0K,
limblocks = 0, mapblocks = 0, maxused = 1K, limit = 39322K, spare = 0,
sizes = (16,32))
kern.malloc.kmemstat.pagedep=(inuse = 1, calls = 1, memuse = 2K,
limblocks = 0, mapblocks = 0, maxused = 2K, limit = 39322K, spare = 0,
sizes = (2048))
kern.malloc.kmemstat.inodedep=(inuse = 1, calls = 1, memuse = 8K,
limblocks = 0, mapblocks = 0, maxused = 8K, limit = 39322K, spare = 0,
sizes = (8192))
kern.malloc.kmemstat.newblk=(inuse = 1, calls = 1, memuse = 1K,
limblocks = 0, mapblocks = 0, maxused = 1K, limit = 39322K, spare = 0,
sizes = (256))
kern.malloc.kmemstat.indirdep=(inuse = 0, calls = 0, memuse = 0K,
limblocks = 0, mapblocks = 0, maxused = 0K, limit = 39322K, spare = 0,
sizes = (none))
kern.malloc.kmemstat.VM_swap=(inuse = 7, calls = 7, memuse = 79K,
limblocks = 0, mapblocks = 0, maxused = 79K, limit = 39322K, spare =
0, sizes = (16,32,2048,65536))
kern.malloc.kmemstat.RAIDframe_data=(inuse = 0, calls = 0, memuse =
0K, limblocks = 0, mapblocks = 0, maxused = 0K, limit = 39322K, spare
= 0, sizes = (none))
kern.malloc.kmemstat.UVM_amap=(inuse = 2927, calls = 28526, memuse =
90K, limblocks = 0, mapblocks = 0, maxused = 111K, limit = 39322K,
spare = 0, sizes = (16,32,64,128,256,512,1024,2048))
kern.malloc.kmemstat.UVM_aobj=(inuse = 2, calls = 2, memuse = 2K,
limblocks = 0, mapblocks = 0, maxused = 2K, limit = 39322K, spare = 0,
sizes = (16,1024))
kern.malloc.kmemstat.USB=(inuse = 74, calls = 74, memuse = 7K,
limblocks = 0, mapblocks = 0, maxused = 7K, limit = 39322K, spare = 0,
sizes = (16,32,64,128,256))
kern.malloc.kmemstat.USB_device=(inuse = 21, calls = 21, memuse = 9K,
limblocks = 0, mapblocks = 0, maxused = 9K, limit = 39322K, spare = 0,
sizes = (16,128,256,512))
kern.malloc.kmemstat.USB_HC=(inuse = 0, calls = 0, memuse = 0K,
limblocks = 0, mapblocks = 0, maxused = 0K, limit = 39322K, spare = 0,
sizes = (none))
kern.malloc.kmemstat.memdesc=(inuse = 0, calls = 0, memuse = 0K,
limblocks = 0, mapblocks = 0, maxused = 0K, limit = 39322K, spare = 0,
sizes = (none))
kern.malloc.kmemstat.crypto_data=(inuse = 1, calls = 1, memuse = 1K,
limblocks = 0, mapblocks = 0, maxused = 1K, limit = 39322K, spare = 0,
sizes = (1024))
kern.malloc.kmemstat.IPsec_creds=(inuse = 0, calls = 0, memuse = 0K,
limblocks = 0, mapblocks = 0, maxused = 0K, limit = 39322K, spare = 0,
sizes = (none))
kern.malloc.kmemstat.packet_tags=(inuse = 0, calls = 0, memuse = 0K,
limblocks = 0, mapblocks = 0, maxused = 0K, limit = 39322K, spare = 0,
sizes = (none))
kern.malloc.kmemstat.1394ctl=(inuse = 0, calls = 0, memuse = 0K,
limblocks = 0, mapblocks = 0, maxused = 0K, limit = 39322K, spare = 0,
sizes = (none))
kern.malloc.kmemstat.1394data=(inuse = 0, calls = 0, memuse = 0K,
limblocks = 0, mapblocks = 0, maxused = 0K, limit = 39322K, spare = 0,
sizes = (none))
kern.malloc.kmemstat.emuldata=(inuse = 0, calls = 0, memuse = 0K,
limblocks = 0, mapblocks = 0, maxused = 0K, limit = 39322K, spare = 0,
sizes = (none))
kern.malloc.kmemstat.ip6_options=(inuse = 0, calls = 0, memuse = 0K,
limblocks = 0, mapblocks = 0, maxused = 0K, limit = 39322K, spare = 0,
sizes = (none))
kern.malloc.kmemstat.NDP=(inuse = 7, calls = 8, memuse = 1K, limblocks
= 0, mapblocks = 0, maxused = 1K, limit = 39322K, spare = 0, sizes =
(64,128))
kern.malloc.kmemstat.ip6rr=(inuse = 0, calls = 0, memuse = 0K,
limblocks = 0, mapblocks = 0, maxused = 0K, limit = 39322K, spare = 0,
sizes = (none))
kern.malloc.kmemstat.rp_addr=(inuse = 0, calls = 0, memuse = 0K,
limblocks = 0, mapblocks = 0, maxused = 0K, limit = 39322K, spare = 0,
sizes = (none))
kern.malloc.kmemstat.temp=(inuse = 39, calls = 4639, memuse = 5K,
limblocks = 0, mapblocks = 0, maxused = 9K, limit = 39322K, spare = 0,
sizes = (16,32,64,256,512,1024,4096))
kern.malloc.kmemstat.NTFS_mount=(inuse = 0, calls = 0, memuse = 0K,
limblocks = 0, mapblocks = 0, maxused = 0K, limit = 39322K, spare = 0,
sizes = (none))
kern.malloc.kmemstat.NTFS_node=(inuse = 0, calls = 0, memuse = 0K,
limblocks = 0, mapblocks = 0, maxused = 0K, limit = 39322K, spare = 0,
sizes = (none))
kern.malloc.kmemstat.NTFS_fnode=(inuse = 0, calls = 0, memuse = 0K,
limblocks = 0, mapblocks = 0, maxused = 0K, limit = 39322K, spare = 0,
sizes = (none))
kern.malloc.kmemstat.NTFS_dir=(inuse = 0, calls = 0, memuse = 0K,
limblocks = 0, mapblocks = 0, maxused = 0K, limit = 39322K, spare = 0,
sizes = (none))
kern.malloc.kmemstat.NTFS_hash_tables=(inuse = 0, calls = 0, memuse =
0K, limblocks = 0, mapblocks = 0, maxused = 0K, limit = 39322K, spare
= 0, sizes = (none))
kern.malloc.kmemstat.NTFS_file_attr=(inuse = 0, calls = 0, memuse =
0K, limblocks = 0, mapblocks = 0, maxused = 0K, limit = 39322K, spare
= 0, sizes = (none))
kern.malloc.kmemstat.NTFS_resident_data_=(inuse = 0, calls = 0, memuse
= 0K, limblocks = 0, mapblocks = 0, maxused = 0K, limit = 39322K,
spare = 0, sizes = (none))
kern.malloc.kmemstat.NTFS_decomp=(inuse = 0, calls = 0, memuse = 0K,
limblocks = 0, mapblocks = 0, maxused = 0K, limit = 39322K, spare = 0,
sizes = (none))
kern.malloc.kmemstat.NTFS_vrun=(inuse = 0, calls = 0, memuse = 0K,
limblocks = 0, mapblocks = 0, maxused = 0K, limit = 39322K, spare = 0,
sizes = (none))
kern.malloc.kmemstat.kqueue=(inuse = 0, calls = 0, memuse = 0K,
limblocks = 0, mapblocks = 0, maxused = 0K, limit = 39322K, spare = 0,
sizes = (none))
kern.malloc.kmemstat.bluetooth=(inuse = 0, calls = 0, memuse = 0K,
limblocks = 0, mapblocks = 0, maxused = 0K, limit = 39322K, spare = 0,
sizes = (none))
kern.malloc.kmemstat.bwmeter=(inuse = 0, calls = 0, memuse = 0K,
limblocks = 0, mapblocks = 0, maxused = 0K, limit = 39322K, spare = 0,
sizes = (none))
kern.malloc.kmemstat.UDF_mount=(inuse = 0, calls = 0, memuse = 0K,
limblocks = 0, mapblocks = 0, maxused = 0K, limit = 39322K, spare = 0,
sizes = (none))
kern.malloc.kmemstat.UDF_file_entry=(inuse = 0, calls = 0, memuse =
0K, limblocks = 0, mapblocks = 0, maxused = 0K, limit = 39322K, spare
= 0, sizes = (none))
kern.malloc.kmemstat.UDF_file_id=(inuse = 0, calls = 0, memuse = 0K,
limblocks = 0, mapblocks = 0, maxused = 0K, limit = 39322K, spare = 0,
sizes = (none))
kern.cp_time=283,0,367,230,334131
kern.nchstats.good_hits=8779
kern.nchstats.negative_hits=277
kern.nchstats.bad_hits=23
kern.nchstats.false_hits=6
kern.nchstats.misses=2813
kern.nchstats.long_names=25
kern.nchstats.pass2=16
kern.nchstats.2passes=55
kern.nchstats.ncs_revhits=0
kern.nchstats.ncs_revmiss=0
kern.forkstat.forks=173
kern.forkstat.vforks=22
kern.forkstat.rforks=0
kern.forkstat.kthreads=16
kern.forkstat.fork_pages=11359
kern.forkstat.vfork_pages=3202
kern.forkstat.rfork_pages=0
kern.forkstat.kthread_pages=0
kern.nselcoll=0
kern.tty.tk_nin=81
kern.tty.tk_nout=103174
kern.tty.tk_rawcc=71
kern.tty.tk_cancc=10
kern.tty.maxptys=992
kern.tty.nptys=64
kern.ccpu=1948
kern.fscale=2048
kern.nprocs=36
kern.stackgap_random=262144
kern.usercrypto=1
kern.cryptodevallowsoft=0
kern.splassert=0
kern.nfiles=63
kern.ttycount=69
kern.numvnodes=1310
kern.userasymcrypto=1
kern.seminfo.semmni=10
kern.seminfo.semmns=60
kern.seminfo.semmnu=30
kern.seminfo.semmsl=60
kern.seminfo.semopm=100
kern.seminfo.semume=10
kern.seminfo.semusz=100
kern.seminfo.semvmx=32767
kern.seminfo.semaem=16384
kern.shminfo.shmmax=33554432
kern.shminfo.shmmin=1
kern.shminfo.shmmni=128
kern.shminfo.shmseg=128
kern.shminfo.shmall=8192
kern.emul.nemuls=6
kern.emul.aout=0
kern.emul.bsdos=0
kern.emul.freebsd=0
kern.emul.ibcs2=0
kern.emul.linux=0
kern.emul.svr4=0
kern.maxclusters=6144
kern.maxlocksperuid=1024
tvc# sysctl kern.maxvnodes kern.numvnodes
kern.maxvnodes=1310
kern.numvnodes=1310
tvc# find /usr/src/sys/ -name "*.[ch]" | xargs grep qwertyuiop
3.132u 2.953s 0:14.74 41.2%     0+0k 8679+99io 19359pf+0w
tvc# find /usr/src/sys/ -name "*.[ch]" | xargs grep qwertyuiop
3.132u 3.070s 0:14.02 44.2%     0+0k 8479+98io 19351pf+0w
tvc# find /usr/src/sys/ -name "*.[ch]" | xargs grep qwertyuiop
3.289u 3.124s 0:14.37 44.5%     0+0k 8487+128io 19351pf+0w
tvc# find /usr/src/sys/ -name "*.[ch]" | xargs grep qwertyuiop
3.078u 3.078s 0:14.08 43.6%     0+0k 8470+97io 19351pf+0w
tvc# sysctl kern.maxvnodes kern.numvnodes
kern.maxvnodes=1310
kern.numvnodes=2621
tvc# date
Sat Feb 18 14:21:14 GMT 2006
tvc# sysctl kern.maxvnodes=20960
kern.maxvnodes: 1310 -> 20960
tvc# sysctl kern.maxvnodes kern.numvnodes
kern.maxvnodes=20960
kern.numvnodes=2621
tvc# find /usr/src/sys/ -name "*.[ch]" | xargs grep qwertyuiop
3.367u 1.421s 0:08.96 53.3%     0+0k 4729+70io 7724pf+0w
tvc# find /usr/src/sys/ -name "*.[ch]" | xargs grep qwertyuiop
3.093u 0.781s 0:05.34 72.4%     0+0k 685+70io 0pf+0w
tvc# sysctl kern.maxvnodes kern.numvnodes
kern.maxvnodes=20960
kern.numvnodes=6765
tvc# find /usr/src/sys/ -name "*.[ch]" | xargs grep qwertyuiop
3.210u 0.703s 0:03.89 100.5%    0+0k 0+70io 0pf+0w
tvc# date
Sat Feb 18 14:25:41 GMT 2006
tvc# find /usr/src/sys/ -name "*.[ch]" | xargs grep qwertyuiop
3.124u 0.742s 0:03.84 100.5%    0+0k 0+70io 0pf+0w
tvc# find /usr/src/sys/ -name "*.[ch]" | xargs grep qwertyuiop
3.273u 0.640s 0:03.90 100.2%    0+0k 0+70io 0pf+0w
tvc# sysctl kern.maxvnodes kern.numvnodes
kern.maxvnodes=20960
kern.numvnodes=6804
tvc# history 20
   210  13:36   idate
   211  14:17   sysctl kern
   212  14:18   sysctl kern.maxvnodes kern.numvnodes
   213  14:18   find /usr/src/sys/ -name "*.[ch]" | xargs grep qwertyuiop
   214  14:19   find /usr/src/sys/ -name "*.[ch]" | xargs grep qwertyuiop
   215  14:19   find /usr/src/sys/ -name "*.[ch]" | xargs grep qwertyuiop
   216  14:20   find /usr/src/sys/ -name "*.[ch]" | xargs grep qwertyuiop
   217  14:21   sysctl kern.maxvnodes kern.numvnodes
   218  14:21   date
   219  14:23   sysctl kern.maxvnodes=20960
   220  14:23   sysctl kern.maxvnodes kern.numvnodes
   221  14:23   find /usr/src/sys/ -name "*.[ch]" | xargs grep qwertyuiop
   222  14:24   find /usr/src/sys/ -name "*.[ch]" | xargs grep qwertyuiop
   223  14:24   sysctl kern.maxvnodes kern.numvnodes
   224  14:25   find /usr/src/sys/ -name "*.[ch]" | xargs grep qwertyuiop
   225  14:25   date
   226  14:26   find /usr/src/sys/ -name "*.[ch]" | xargs grep qwertyuiop
   227  14:30   find /usr/src/sys/ -name "*.[ch]" | xargs grep qwertyuiop
   228  14:31   sysctl kern.maxvnodes kern.numvnodes
   229  14:32   history 20
tvc#





Here is the most recent dmesg of this ASUS Terminator C3:

OpenBSD 3.9-beta (GENERIC) #601: Sun Feb 12 21:39:52 MST 2006
    [hidden email]:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: VIA Samuel 2 ("CentaurHauls" 686-class) 800 MHz
cpu0: FPU,DE,TSC,MSR,MTRR,PGE,MMX
real mem  = 502833152 (491048K)
avail mem = 451723264 (441136K)
using 4278 buffers containing 25243648 bytes (24652K) of memory
mainbus0 (root)
bios0 at mainbus0: AT/286+(63) BIOS, date 01/06/05, BIOS32 rev. 0 @ 0xfbba0
apm0 at bios0: Power Management spec V1.2
apm0: AC on, battery charge unknown
apm0: flags 70102 dobusy 1 doidle 1
pcibios0 at bios0: rev 2.1 @ 0xf0000/0xdfa4
pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xfdf20/128 (6 entries)
pcibios0: PCI Exclusive IRQs: 5 10 11
pcibios0: PCI Interrupt Router at 000:17:0 ("VIA VT82C596A ISA" rev 0x00)
pcibios0: PCI bus #1 is the last bus
bios0: ROM list: 0xc0000/0xf200 0xd0000/0x8000!
cpu0 at mainbus0
pci0 at mainbus0 bus 0: configuration mode 1 (no bios)
pchb0 at pci0 dev 0 function 0 "VIA VT8623 PCI" rev 0x00
ppb0 at pci0 dev 1 function 0 "VIA VT8633 AGP" rev 0x00
pci1 at ppb0 bus 1
vga1 at pci1 dev 0 function 0 "VIA CLE266" rev 0x03: aperture at
0xe4000000, size 0x10000000
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
"VIA VT6306 FireWire" rev 0x80 at pci0 dev 9 function 0 not configured
pciide0 at pci0 dev 15 function 0 "VIA VT6420 SATA" rev 0x80: DMA
pciide0: using irq 11 for native-PCI interrupt
pciide1 at pci0 dev 15 function 1 "VIA VT82C571 IDE" rev 0x06: DMA,
channel 0 configured to compatibility, channel 1 configured to
compatibility
wd0 at pciide1 channel 0 drive 0: <HDS722580VLAT20>
wd0: 16-sector PIO, LBA48, 78533MB, 160836480 sectors
atapiscsi0 at pciide1 channel 0 drive 1
scsibus0 at atapiscsi0: 2 targets
cd0 at scsibus0 targ 0 lun 0: <ASUS, CD-S520/A4, 1.32> SCSI0 5/cdrom removable
wd0(pciide1:0:0): using PIO mode 4, DMA mode 2
cd0(pciide1:0:1): using PIO mode 4, DMA mode 2
pciide1: channel 1 disabled (no drives)
uhci0 at pci0 dev 16 function 0 "VIA VT83C572 USB" rev 0x81: irq 10
usb0 at uhci0: USB revision 1.0
uhub0 at usb0
uhub0: VIA UHCI root hub, rev 1.00/1.00, addr 1
uhub0: 2 ports with 2 removable, self powered
uhci1 at pci0 dev 16 function 1 "VIA VT83C572 USB" rev 0x81: irq 10
usb1 at uhci1: USB revision 1.0
uhub1 at usb1
uhub1: VIA UHCI root hub, rev 1.00/1.00, addr 1
uhub1: 2 ports with 2 removable, self powered
uhci2 at pci0 dev 16 function 2 "VIA VT83C572 USB" rev 0x81: irq 11
usb2 at uhci2: USB revision 1.0
uhub2 at usb2
uhub2: VIA UHCI root hub, rev 1.00/1.00, addr 1
uhub2: 2 ports with 2 removable, self powered
uhci3 at pci0 dev 16 function 3 "VIA VT83C572 USB" rev 0x81: irq 11
usb3 at uhci3: USB revision 1.0
uhub3 at usb3
uhub3: VIA UHCI root hub, rev 1.00/1.00, addr 1
uhub3: 2 ports with 2 removable, self powered
ehci0 at pci0 dev 16 function 4 "VIA VT6202 USB" rev 0x86: irq 5
usb4 at ehci0: USB revision 2.0
uhub4 at usb4
uhub4: VIA EHCI root hub, rev 2.00/1.00, addr 1
uhub4: 8 ports with 8 removable, self powered
viapm0 at pci0 dev 17 function 0 "VIA VT8237 ISA" rev 0x00
iic0 at viapm0
auvia0 at pci0 dev 17 function 5 "VIA VT8233 AC97" rev 0x60: irq 5
ac97: codec id 0x41445368 (Analog Devices AD1888)
ac97: codec features headphone, 20 bit DAC, No 3D Stereo
audio0 at auvia0
vr0 at pci0 dev 18 function 0 "VIA RhineII-2" rev 0x78: irq 10,
address 00:11:d8:xx:xx:xx
ukphy0 at vr0 phy 1: Generic IEEE 802.3u media interface, rev. 10: OUI
0x004063, model 0x0032
isa0 at mainbus0
isadma0 at isa0
pckbc0 at isa0 port 0x60/5
pckbd0 at pckbc0 (kbd slot)
pckbc0: using irq 1 for kbd slot
wskbd0 at pckbd0: console keyboard, using wsdisplay0
pcppi0 at isa0 port 0x61
midi0 at pcppi0: <PC speaker>
spkr0 at pcppi0
lpt0 at isa0 port 0x378/4 irq 7
lm0 at isa0 port 0x290/8: W83627THF
npx0 at isa0 port 0xf0/16: using exception 16
pccom0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
pccom0: console
fdc0 at isa0 port 0x3f0/6 irq 6 drq 2
fd0 at fdc0 drive 0: 1.44MB 80 cyl, 2 head, 18 sec
biomask ff6d netmask ff6d ttymask ffef
pctr: user-level cycle counter enabled
dkcsum: wd0 matches BIOS drive 0x80
root on wd0a
rootdev=0x0 rrootdev=0x300 rawdev=0x302


Cheers,
Constantine.

Reply | Threaded
Open this post in threaded view
|

Re: Utilisation of free memory as disc cache: tweaking is required?

Hannah Schroeter
Hello!

On Sat, Feb 18, 2006 at 03:40:48PM +0000, Constantine A. Murenin wrote:
>I have a box with 512MB of RAM, which is running a snapshot from 2006-02-13.

>The box does not get used much, so most of the RAM stays still, i.e.
>not used by the userland.

>I am now quite surprised why OpenBSD does not use all of this RAM for
>disc cache etc.

Because nobody has submitted code that actually gets it right. There
was code for unified VM/buffer cache in the tree once, but got reverted
a few weeks later when it showed itself that there were significant
problems with it.

Just one "effect" you have to care for, on Linux (which *has* a unified
VM/buffer cache system) we mkdir many directories (e.g. hashed buckets
like squid uses them, just a few more, 256 * 256, to be precise). It was
quite long (at least into the Linux 2.4 series) that that worked like
this: mkdir completed quite fast until the memory was filled with dirty
blocks, then the box *hung* completely until all the dirty blocks were
actually written to disk. This isn't acceptable. And it's not acceptable
for something like grep foo (a list of names of long files) pages out
every program.

Just two things where it shows how difficult it can be to get things
right. It's much easier to get it right as it is in OpenBSD.

>[...]

Kind regards,

Hannah.

Reply | Threaded
Open this post in threaded view
|

Re: Utilisation of free memory as disc cache: tweaking is required?

Constantine A. Murenin
Hi!

On 20/02/06, Hannah Schroeter <[hidden email]> wrote:

> Hello!
>
> On Sat, Feb 18, 2006 at 03:40:48PM +0000, Constantine A. Murenin wrote:
> >I have a box with 512MB of RAM, which is running a snapshot from 2006-02-13.
>
> >The box does not get used much, so most of the RAM stays still, i.e.
> >not used by the userland.
>
> >I am now quite surprised why OpenBSD does not use all of this RAM for
> >disc cache etc.
>
> Because nobody has submitted code that actually gets it right. There
> was code for unified VM/buffer cache in the tree once, but got reverted
> a few weeks later when it showed itself that there were significant
> problems with it.
>
> Just one "effect" you have to care for, on Linux (which *has* a unified
> VM/buffer cache system) we mkdir many directories (e.g. hashed buckets
> like squid uses them, just a few more, 256 * 256, to be precise). It was
> quite long (at least into the Linux 2.4 series) that that worked like
> this: mkdir completed quite fast until the memory was filled with dirty
> blocks, then the box *hung* completely until all the dirty blocks were
> actually written to disk. This isn't acceptable. And it's not acceptable
> for something like grep foo (a list of names of long files) pages out
> every program.
>
> Just two things where it shows how difficult it can be to get things
> right. It's much easier to get it right as it is in OpenBSD.

Yes, there is always some compromise. But in this specific case we
have much less than even a fifth of memory actually being used for
programmes and kernel etc. Some of the rest is used for cache, but it
still stops at around 3/4 or even 4/5 of the memory being wasted for
nothing.

We are not dealing here with a case of someone wanting to use the
remaining 64MB for disc cache on a 2GB server (assuming the rest of
memory being already utilised for cache): -- this is a case of a 512MB
machine behaving as if it was a 128MB one, not using the extra 3/4 of
available memory. I assume that even if I put the extra 1G in, the
proportion of wasted memory will only increase.

And 512MB, I must add, is the de facto minimum today for any machine,
making this even lack of tune-up even more unacceptable.

Cheers,
Constantine.

Reply | Threaded
Open this post in threaded view
|

Re: Utilisation of free memory as disc cache: tweaking is required?

Antonios Anastasiadis
if it's unacceptable to you, either don't use openbsd or submit a patch.

Reply | Threaded
Open this post in threaded view
|

Re: Utilisation of free memory as disc cache: tweaking is required?

Hannah Schroeter
In reply to this post by Constantine A. Murenin
Hello!

On Mon, Feb 20, 2006 at 01:17:05PM +0000, Constantine A. Murenin wrote:
>[...]

>Yes, there is always some compromise. But in this specific case we
>have much less than even a fifth of memory actually being used for
>programmes and kernel etc. Some of the rest is used for cache, but it
>still stops at around 3/4 or even 4/5 of the memory being wasted for
>nothing.

>We are not dealing here with a case of someone wanting to use the
>remaining 64MB for disc cache on a 2GB server (assuming the rest of
>memory being already utilised for cache): -- this is a case of a 512MB
>machine behaving as if it was a 128MB one, not using the extra 3/4 of
>available memory. I assume that even if I put the extra 1G in, the
>proportion of wasted memory will only increase.

If this is a common state of affairs, you can always raise the
percentage of memory used for the buffer cache in the kernel, using
config -e: config -e -o /bsd.new /bsd
then the command
         cachepct    [number]            Show/change BUFCACHEPERCENT
helps. The default is 5, you could raise it to 10 or even more.

>And 512MB, I must add, is the de facto minimum today for any machine,
>making this even lack of tune-up even more unacceptable.

OpenBSD doesn't run only on i386/amd64, remember this. And until
recently, my home machine still had 96 MB RAM.

>Cheers,
>Constantine.

Kind regards,

Hannah.

Reply | Threaded
Open this post in threaded view
|

Re: Utilisation of free memory as disc cache: tweaking is required?

Stuart Henderson
In reply to this post by Constantine A. Murenin
On 2006/02/20 13:17, Constantine A. Murenin wrote:
> And 512MB, I must add, is the de facto minimum today for any machine,

For Windows PCs, maybe... Of the machines I have running OpenBSD, 64MB
is the most common RAM size, and those boxes are doing useful work.

> making this even lack of tune-up even more unacceptable.

Well, if you think you can do better than the default, you can look
at machdep.c and work out how to adjust it.

Reply | Threaded
Open this post in threaded view
|

Re: Utilisation of free memory as disc cache: tweaking is required?

Shane J Pearson
In reply to this post by Hannah Schroeter
Hi Hannah,

On 2006.02.20, at 11:21 PM, Hannah Schroeter wrote:

> Just one "effect" you have to care for, on Linux (which *has* a  
> unified
> VM/buffer cache system) we mkdir many directories (e.g. hashed buckets
> like squid uses them, just a few more, 256 * 256, to be precise).  
> It was
> quite long (at least into the Linux 2.4 series) that that worked like
> this: mkdir completed quite fast until the memory was filled with  
> dirty
> blocks, then the box *hung* completely until all the dirty blocks were
> actually written to disk. This isn't acceptable. And it's not  
> acceptable
> for something like grep foo (a list of names of long files) pages out
> every program.

The Linux UBC doesn't seem to perform very well either. Assuming I  
tested this correctly, I wrote a simple script to read a large file  
(larger than half available RAM but less than total available), over  
and over again (hundreds of times) just to /dev/null. NetBSD and  
FreeBSD read the file from disk once, as noted from the activity  
light and then flew through the remaining re-reads super fast from  
RAM (FreeBSD being the faster of the two). I expected this behaviour  
from Linux, but instead Linux constantly read the file from disk  
_extremely_ slowly (found on various Linux distros). Much much slower  
than OpenBSD which also read the file from disk each time.

Is OpenBSD way too different now from NetBSD to port their UBC code?


Shane J Pearson        shanejp netspace net au

Reply | Threaded
Open this post in threaded view
|

Re: Utilisation of free memory as disc cache: tweaking is required?

Constantine A. Murenin
In reply to this post by Hannah Schroeter
On 20/02/06, Hannah Schroeter <[hidden email]> wrote:

> Hello!
>
> On Mon, Feb 20, 2006 at 01:17:05PM +0000, Constantine A. Murenin wrote:
> >[...]
>
> >Yes, there is always some compromise. But in this specific case we
> >have much less than even a fifth of memory actually being used for
> >programmes and kernel etc. Some of the rest is used for cache, but it
> >still stops at around 3/4 or even 4/5 of the memory being wasted for
> >nothing.
>
> >We are not dealing here with a case of someone wanting to use the
> >remaining 64MB for disc cache on a 2GB server (assuming the rest of
> >memory being already utilised for cache): -- this is a case of a 512MB
> >machine behaving as if it was a 128MB one, not using the extra 3/4 of
> >available memory. I assume that even if I put the extra 1G in, the
> >proportion of wasted memory will only increase.
>
> If this is a common state of affairs, you can always raise the
> percentage of memory used for the buffer cache in the kernel, using
> config -e: config -e -o /bsd.new /bsd
> then the command
>          cachepct    [number]            Show/change BUFCACHEPERCENT
> helps. The default is 5, you could raise it to 10 or even more.

Thanks, I think this is indeed an option I was looking for (however,
it looks like I was looking for it in the wrong place -- `sysctl kern`
tree).

Although the documentation says that it defaults to 5%, it actually
seems to default to 10% on amd64, alpha, hppa and hppa64.

Why it's not made to default to 10% on i386 too if enough memory is available?

Also, it looks like "Filesystem Buffer" was in the FAQ in 2003-05-01
(http://www.se.openbsd.org/faq/faq11.html), stating "option
BUFCACHEPERCENT=30" for config(8), but now it no longer appears in
today's version (http://www.openbsd.org/faq/faq11.html). Is there a
reason for that?

> >And 512MB, I must add, is the de facto minimum today for any machine,
> >making this even lack of tune-up even more unacceptable.
>
> OpenBSD doesn't run only on i386/amd64, remember this. And until
> recently, my home machine still had 96 MB RAM.

True, I was making a generalisation to mean any modern PC/mac. :-) It
was almost a year ago that 512MB became the minimum even for most
entry models.

Cheers,
Constantine.

Reply | Threaded
Open this post in threaded view
|

Re: Utilisation of free memory as disc cache: tweaking is required?

Constantine A. Murenin
In reply to this post by Stuart Henderson
On 20/02/06, Stuart Henderson <[hidden email]> wrote:
> On 2006/02/20 13:17, Constantine A. Murenin wrote:
> > And 512MB, I must add, is the de facto minimum today for any machine,
>
> For Windows PCs, maybe... Of the machines I have running OpenBSD, 64MB
> is the most common RAM size, and those boxes are doing useful work.

To avoid any further confusion: by saying "512 de facto" I was
referring to the newly produced  machines, be that any factory or home
assembled PCs or Macs. Clearly, one would not upgrade an old firewall
to have out of a sudden 512MB of RAM. But if you are building a new
one, I doubt that you'll find it economically feasible to buy a DDR
module <=256MB.


> > making this even lack of tune-up even more unacceptable.
>
> Well, if you think you can do better than the default, you can look
> at machdep.c and work out how to adjust it.

Yes, now that Hannah showed me the option, I'll do just that. :-)

Cheers,
Constantine.

Reply | Threaded
Open this post in threaded view
|

Re: Utilisation of free memory as disc cache: tweaking is required?

Hannah Schroeter
In reply to this post by Constantine A. Murenin
Hello!

On Mon, Feb 20, 2006 at 02:49:01PM +0000, Constantine A. Murenin wrote:
>[...]

>> If this is a common state of affairs, you can always raise the
>> percentage of memory used for the buffer cache in the kernel, using
>> config -e: config -e -o /bsd.new /bsd
>> then the command
>>          cachepct    [number]            Show/change BUFCACHEPERCENT
>> helps. The default is 5, you could raise it to 10 or even more.

>Thanks, I think this is indeed an option I was looking for (however,
>it looks like I was looking for it in the wrong place -- `sysctl kern`
>tree).

This can't be changed during run-time.

>Although the documentation says that it defaults to 5%, it actually
>seems to default to 10% on amd64, alpha, hppa and hppa64.

>Why it's not made to default to 10% on i386 too if enough memory is available?

Others need more memory for running programs than you might need.

>Also, it looks like "Filesystem Buffer" was in the FAQ in 2003-05-01
>(http://www.se.openbsd.org/faq/faq11.html), stating "option
>BUFCACHEPERCENT=30" for config(8), but now it no longer appears in
>today's version (http://www.openbsd.org/faq/faq11.html). Is there a
>reason for that?

Because that's not longer the recommended way. The recommendation is
to use GENERIC and at most customize it with config -e. Of course,
option BUFCACHEPERCENT=... still works, but is not officially supported,
like any building of custom kernels.

>> >And 512MB, I must add, is the de facto minimum today for any machine,
>> >making this even lack of tune-up even more unacceptable.

>> OpenBSD doesn't run only on i386/amd64, remember this. And until
>> recently, my home machine still had 96 MB RAM.

>True, I was making a generalisation to mean any modern PC/mac. :-) It
>was almost a year ago that 512MB became the minimum even for most
>entry models.

So then. Not everyone buys a new computer every year.

>Cheers,
>Constantine.

Kind regards,

Hannah.

Reply | Threaded
Open this post in threaded view
|

Re: Utilisation of free memory as disc cache: tweaking is required?

Nick Holland-2
In reply to this post by Constantine A. Murenin
On Mon, Feb 20, 2006 at 02:49:01PM +0000, Constantine A. Murenin wrote:
...
> Although the documentation says that it defaults to 5%, it actually
> seems to default to 10% on amd64, alpha, hppa and hppa64.
>
> Why it's not made to default to 10% on i386 too if enough memory is available?
 
because 5% more of 24M or 16M makes a big difference, perhaps?

yes, we care about OpenBSD working well on Really Small Machines.

> Also, it looks like "Filesystem Buffer" was in the FAQ in 2003-05-01
> (http://www.se.openbsd.org/faq/faq11.html), stating "option
> BUFCACHEPERCENT=30" for config(8), but now it no longer appears in
> today's version (http://www.openbsd.org/faq/faq11.html). Is there a
> reason for that?

Yes, because people who thought they knew more than the programmers
kept twisting knobs to the max and expected things to ALWAYS be better,
and we spent too much time reading and answering "IT BROKE!" questions.

This way, we can laugh at people who break their systems in clear
conscience.

Come on, think.
Do you really think OpenBSD developers LIKE to have things go slower
than they could Just Because they like to watch people twist knobs?  Do
you think if they felt there was a better OVER ALL value, they wouldn't
set it?  Not all the world shares your design criteria.

...
> True, I was making a generalisation to mean any modern PC/mac. :-) It
> was almost a year ago that 512MB became the minimum even for most
> entry models.

How about this:
Consider i386 a legacy platform.
All modern stuff is amd64 compatable, anyway, right?
Wow, look at that.  amd64 (which probably will never be seen with less
than 256M due to the memory design) has a default of 10%.

The developers are ahead of you on that. :)

Nick.

Reply | Threaded
Open this post in threaded view
|

Re: Utilisation of free memory as disc cache: tweaking is required?

Constantine A. Murenin
In reply to this post by Hannah Schroeter
On 20/02/06, Hannah Schroeter <[hidden email]> wrote:

> Hello!
>
> On Mon, Feb 20, 2006 at 02:49:01PM +0000, Constantine A. Murenin wrote:
> >[...]
>
> >> If this is a common state of affairs, you can always raise the
> >> percentage of memory used for the buffer cache in the kernel, using
> >> config -e: config -e -o /bsd.new /bsd
> >> then the command
> >>          cachepct    [number]            Show/change BUFCACHEPERCENT
> >> helps. The default is 5, you could raise it to 10 or even more.
>
> >Thanks, I think this is indeed an option I was looking for (however,
> >it looks like I was looking for it in the wrong place -- `sysctl kern`
> >tree).
>
> This can't be changed during run-time.

Yes, after not finding it in sysctl kern, I now see that one can't
change it at runtime. :-(

> >Although the documentation says that it defaults to 5%, it actually
> >seems to default to 10% on amd64, alpha, hppa and hppa64.
>
> >Why it's not made to default to 10% on i386 too if enough memory is available?
>
> Others need more memory for running programs than you might need.
>
> >Also, it looks like "Filesystem Buffer" was in the FAQ in 2003-05-01
> >(http://www.se.openbsd.org/faq/faq11.html), stating "option
> >BUFCACHEPERCENT=30" for config(8), but now it no longer appears in
> >today's version (http://www.openbsd.org/faq/faq11.html). Is there a
> >reason for that?
>
> Because that's not longer the recommended way. The recommendation is
> to use GENERIC and at most customize it with config -e. Of course,
> option BUFCACHEPERCENT=... still works, but is not officially supported,
> like any building of custom kernels.

The old FAQ lists "option BUFCACHEPERCENT=..." as a command to config
-e, not as a compile option, so it's still unclear why the useful
entry was removed from the FAQ.


Cheers,
Constantine.