From owner-freebsd-hackers Thu Mar 7 22:52:32 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from earth.rila.bg (earth.rila.bg [194.141.1.31]) by hub.freebsd.org (Postfix) with ESMTP id EFC5137B400 for ; Thu, 7 Mar 2002 22:52:26 -0800 (PST) Received: from earth.rila.bg (mitko@localhost.rila.bg [127.0.0.1]) by earth.rila.bg (8.11.6/8.11.6) with SMTP id g286oWJ48670; Fri, 8 Mar 2002 08:50:33 +0200 (EET) (envelope-from mitko@rila.bg) Date: Fri, 8 Mar 2002 08:50:32 +0200 From: Dimitar Peikov To: Matthew Dillon Cc: drwilco@drwilco.net, silby@silby.com, bifrost@minions.com, cjp@sandstorm.net, freebsd-hackers@FreeBSD.ORG Subject: Re: Swapping performance Message-Id: <20020308085032.69568968.mitko@rila.bg> In-Reply-To: <200203071912.g27JC3A68645@apollo.backplane.com> References: <20020307095452.D18855-100000@frond.minions.com> <5.1.0.14.0.20020307193205.01c3b0f0@mail.drwilco.net> <200203071912.g27JC3A68645@apollo.backplane.com> Reply-To: mitko@rila.bg Organization: Rila Solutions X-Mailer: Sylpheed version 0.7.2claws (GTK+ 1.2.10; i386--freebsd4.5) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 On Thu, 7 Mar 2002 11:12:03 -0800 (PST) Matthew Dillon wrote: > Hmm. well, I don't think this test is very meaningful. If the > machines have 256M of ram and the test is doing a two-swipe access of > 256M of VM. This doesn't represent any real test and I would not be > surprised by the difference in timing. > > It all comes down to how much real memory Linux and FreeBSD give to > the process and there is no right answer to the question because it's > a tradeoff. An OS does not magically know that only one process will > ever need all of the machine's resources, for example, so different > operating systems are going to have very different characteristics > under these sorts of conditions. One might give over more memory, > another might want to avoid completely blowing away its other caches. > One might work well for linux in a one-process memory test could fail > miserably in a multi-process memory test, for example, or with a > different pattern of memory accesses, or a different load split > between cpu, memory, and disk I/O. > > You (Dimitar and others) also need to be careful about making broad > generalizations. Testing pure swapping performance with the below > program implies that you intend to run applications that will need to > swap heavily (for example, big mathmatical applications). If you > don't intend to run applications that will need to swap heavily then > this test is fairly meaningless as a measure of performance. > I don't make any generalizations if I can't prove that for myself. If I increase the amount of MALLOC_SIZE in this test, the results goes much more worse. Even in case that I have 25 processes running concurently with this task (there is no X, almost empty system), the program runs but ... > Another point that I should bring up in regards to swap performance: > systems that require good swap performance will almost always have > more then one physical disk to swap to. FreeBSD is very good at > paging to swap with a single disk, but it kicks ass paging to swap > with multiple disks because it implements a very good interleaving > algorithm. > > -Matt > Matthew Dillon > > > :Am I the only one who saw that he attached it to his 1st mail? > : > :Here you go: > : > :#include > :#include > :#include > : > :#define MALLOC_SIZE 1024*1024*256 > : > :int main(int argc, char **argv) { > : char *ptr; > : int i, i_count; > : int j; > : > : ptr = (char *) malloc(MALLOC_SIZE); > : bzero(ptr, MALLOC_SIZE); > : > : i_count = MALLOC_SIZE / 16; > : fprintf(stderr, "*"); > : for (i = 0; i < i_count; i ++) { > : ptr[i >> 4] = ptr[(i >> 3) + 1]++; > : } > : fprintf(stderr, "#"); > : for (j = 0; j < i_count; j ++) { > : ptr[j << 4] = ptr[(j >> 3) + 1]++; > : } > : > : free(ptr); > : return 0; > :} -- 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