Date: Fri, 8 Mar 2002 08:50:32 +0200 From: Dimitar Peikov <mitko@rila.bg> To: Matthew Dillon <dillon@apollo.backplane.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 7 Mar 2002 11:12:03 -0800 (PST)
Matthew Dillon <dillon@apollo.backplane.com> 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
> <dillon@backplane.com>
>
> :Am I the only one who saw that he attached it to his 1st mail?
> :
> :Here you go:
> :
> :#include <stdlib.h>
> :#include <string.h>
> :#include <stdio.h>
> :
> :#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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020308085032.69568968.mitko>