From owner-freebsd-hackers Thu Mar 7 6:49:20 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from sandbox.sandstorm.net (user-v3qtgdr.biz.mindspring.com [199.174.193.187]) by hub.freebsd.org (Postfix) with ESMTP id C781037B42F for ; Thu, 7 Mar 2002 06:49:03 -0800 (PST) Received: from innsmouth.sandstorm.net (eight) [199.174.193.186] by sandbox.sandstorm.net with smtp (Exim 2.05 #2 (Debian)) id 16izCV-0004qF-00; Thu, 7 Mar 2002 09:48:59 -0500 Message-ID: <05fe01c1c5e6$6a02e890$2400010a@eight> From: "cjp" To: , References: <20020307104518.0f73740b.mitko@rila.bg> Subject: Re: Swapping performance Date: Thu, 7 Mar 2002 09:42:44 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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. 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" To: 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 > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message