Re: Utilisation of free memory as disc cache: tweaking is required?
if it's unacceptable to you, either don't use openbsd or submit a patch.
Re: Utilisation of free memory as disc cache: tweaking is required?
Hello! On Mon, Feb 20, 2006 at 01:17:05PM +, 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.
Re: Utilisation of free memory as disc cache: tweaking is required?
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.
Re: Utilisation of free memory as disc cache: tweaking is required?
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 Pearsonshanejp netspace net au
Re: Utilisation of free memory as disc cache: tweaking is required?
On 20/02/06, Hannah Schroeter [EMAIL PROTECTED] wrote: Hello! On Mon, Feb 20, 2006 at 01:17:05PM +, 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.
Re: Utilisation of free memory as disc cache: tweaking is required?
On 20/02/06, Stuart Henderson [EMAIL PROTECTED] 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.
Re: Utilisation of free memory as disc cache: tweaking is required?
Hello! On Mon, Feb 20, 2006 at 02:49:01PM +, 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.
Re: Utilisation of free memory as disc cache: tweaking is required?
On Mon, Feb 20, 2006 at 02:49:01PM +, 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.
Re: Utilisation of free memory as disc cache: tweaking is required?
On 20/02/06, Hannah Schroeter [EMAIL PROTECTED] wrote: Hello! On Mon, Feb 20, 2006 at 02:49:01PM +, 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.
Utilisation of free memory as disc cache: tweaking is required?
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 [EMAIL PROTECTED]:/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 = 1, 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)
