Date: Thu, 7 Mar 2002 09:59:06 -0800 (PST) From: Tom <bifrost@minions.com> To: Dimitar Peikov <mitko@rila.bg> Cc: cjp <cjp@sandstorm.net>, <freebsd-hackers@freebsd.org> Subject: Re: Swapping performance Message-ID: <20020307095452.D18855-100000@frond.minions.com> In-Reply-To: <20020307165851.79f391f3.mitko@rila.bg>
next in thread | previous in thread | raw e-mail | index | archive | help
> > This is a comparison of how fast Linux can do something > > STUPID versus how fast a real OS can do something intelligently. Your > > test is giving you misleading, and dangerous numbers. Do not go waving > > them around until you have actually looked at mallocs behavior on the > > different systems. > > In fact if I have to compute something really important for me (STUPID as > you said) I would choose the fastest OS. But when you lose that data, do you not get burnt by that same situation? I have written a 1GB file to a linux box, and then within 5 seconds of it finishing, yanked the power cord. When I booted it back up, the file was *JUST NOT THERE*, I tried it a few other times, and there were fragments that showed up. Under FreeBSD I tried the same test, The file was there, and it finished faster than Linux did. Why is this? Bad procedure to gain file system speed (from what I can tell). Which would you rather have? Fast Calculations, or the results of your data. Obviously its your choice :) > > Here's why: > > > > Linux implements a brain dead memory allocation > > scheme called memory overcommit. It will let you malloc > > as much memory as you want whether it is available as RAM or not > > and only bitch when you try to use the memory. Therefore, > > Linux malloc is much faster than any reasonable system, since all it is > > doing is handing out address space out of unallocated address space, > > not keeping track of how much memory there actually is. > > > > In order to handle the kruft that occurs, there is the out of memory > > killer, oom_killer. > > Which merrily goes through the list of processes, killing off the low > > priority processes > > until enough memory is free to satisfy what was most recently used. It's > > the loan shark > > repayment program, with OOMKiller performing the function of the > > deliquency reminder. > > > > On any of the BSD system, you actually get memory you can use, and all the > > overhead > > of assuring its existence at the time of allocation. Much more robust, > > less prone to abuse. > > > > Try it, you'll like it. If you want the nuts and bolts of it, read the > > source. > > > > > > ----- Original Message ----- > > From: "Dimitar Peikov" <mitko@rila.bg> > > To: <freebsd-hackers@freebsd.org> > > Sent: Thursday, March 07, 2002 3:45 AM > > Subject: Swapping performance > > > > > > > I start some performance tests on -stable and on SuSE 7.1 / 2.4.17. I > > > don't comment about 'bzero' performance, but when RAM is over, Linux > > > is much faster. I have no idea what is the algorithm of swapping but it > > > seems that the granularity of swapping pieces is the key or the > > > importance of swapping memory blocks of certain task. Ooo I forgot to > > > say that the both machines have the same hardware, IBM 300PL, 256 RAM > > > and no other tasks running. I had to run these tests to choose the > > > fastest platform for building our software indexes, which requires a lot > > > of math and memory operations. > > > > > > --- with bzero --- > > > Linux$ time ./malloc_test > > > *# > > > real 0m37.640s > > > user 0m1.370s > > > sys 0m2.950s > > > Linux$ > > > > > > FreeBSD$ time ./malloc_test > > > *# > > > real 0m46.640s > > > user 0m2.280s > > > sys 0m2.550s > > > FreeBSD$ > > > > > > --- without bzero --- > > > Linux$ time ./malloc_test > > > *# > > > real 0m6.371s > > > user 0m0.450s > > > sys 0m1.510s > > > Linux$ > > > > > > FreeBSD$ time ./malloc_test > > > *# > > > real 0m11.571s > > > user 0m1.150s > > > sys 0m1.830s > > > FreeBSD$ > > > > > > > > > > > > -- > > > Dimitar Peikov > > > Programmer Analyst > > > Globalization Group > > > "We Build e-Business" > > > > > > RILA Solutions > > > 27 Building, Acad.G.Bonchev Str. > > > 1113 Sofia, Bulgaria > > > > > > phone: (+359 2) 9797320 > > > phone: (+359 2) 9797300 > > > fax: (+359 2) 9733355 > > > http://www.rila.com --- Tom bifrost@minions.com "Where am I and why am I in this handbasket?" Beat up a Spammer today - http://spamhaus.org/ tistom et ha'peh ve tavi li birra... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020307095452.D18855-100000>