Giorgos Keramidas wrote:
> On 2002-03-07 16:45, Simon 'corecode' Schubert wrote:
> > to everybody who doesn't believe that: it really generates bad code.
> > i've been having severe problems with my tcp and udp stack lately (on a
> > i586/mmx machine). guess what, -O2 resulted in code which >>some
On 2002-03-07 16:45, Simon 'corecode' Schubert wrote:
> to everybody who doesn't believe that: it really generates bad code.
> i've been having severe problems with my tcp and udp stack lately (on a
> i586/mmx machine). guess what, -O2 resulted in code which >>sometimes<<
> generated bad tcp and/
On Fri, 8 Mar 2002, David Xu wrote:
> Unfortunately, I havn't Linux kernel 2.4.17 installed, is Linux kernel 2.4.17
>faster?
> --
> David Xu
Well, the VM in it is certainly different. Since he's using SUSE 2.4.17,
I believe that would mean that he's actually using 2.4.17-AA; you'd want
to tr
David Xu wrote:
> I have done some tests on my machine, the machine has both
> Linux and FreeBSD installed, the following is the data:
>
> MALLOC_SIZE = 1024*1024*400
> has bzero
>
> Red Linux 6.2(kernel 2.2.14)
> 5.09u 5.62s 1:15.33 14%
> 4.70u 5.73s 1:17.13 13%
> 4.88u 5.68s 1:17
I have done some tests on my machine, the machine has both Linux and FreeBSD
installed,
the following is the data:
MALLOC_SIZE = 1024*1024*400
has bzero
Red Linux 6.2(kernel 2.2.14)
5.09user 5.62system 1:15.33elapsed 14%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (115298majo
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 mathmat
On Thu, 07 Mar 2002 11:19:25 -0800
Terry Lambert <[EMAIL PROTECTED]> wrote:
> > #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(MALL
On Thu, 7 Mar 2002 10:42:05 -0800
"David O'Brien" <[EMAIL PROTECTED]> wrote:
> On Thu, Mar 07, 2002 at 08:09:06AM -0600, GB Clark wrote:
> > > I've tested it with :
> > >
> > > cc -O6 -o malloc_test malloc_test.c
> >
> > That -O6 does not look right from here. Do we support anything over
> > -
On Thu, 7 Mar 2002 11:41:28 + (GMT)
Mike Silbersack <[EMAIL PROTECTED]> wrote:
>
> On Thu, 7 Mar 2002, cjp wrote:
>
> > 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
> >
>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
Simon 'corecode' Schubert wrote:
> > Are you using NAT?
>
> yep.
>
> > The libalias incremental checksum calculation is incorrect;
> > it assumes that a two's complement network order underflow
> > will result in the same value as a one's complement host
> > order underflow. This results in off
Matthew Dillon wrote:
> :The bzero is unnecessary on FreeBSD. Allocated pages start out
> :zero'ed. Part of the performance issue might be that FreeBSD is
> :being asked to zero the pages twice, instead of once.
>
> malloc() does not guarentee a zero'd page, even though the
> side effec
On Thu, 07 Mar 2002 10:49:22 -0800 Terry Lambert <[EMAIL PROTECTED]> wrote:
> Simon 'corecode' Schubert wrote:
> > to everybody who doesn't believe that: it really generates bad code.
> > i've been having severe problems with my tcp and udp stack lately (on a
> > i586/mmx machine). guess what, -O
:>ptr = (char *) malloc(MALLOC_SIZE);
:>bzero(ptr, MALLOC_SIZE);
:
:The bzero is unnecessary on FreeBSD. Allocated pages start out
:zero'ed. Part of the performance issue might be that FreeBSD is
:being asked to zero the pages twice, instead of once.
malloc() does not guarentee a z
> #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);
The bzero is unnecessary on FreeBSD. Allocated pages start
ess 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
prog
:...
:> > 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
:>
On Thu, Mar 07, 2002 at 11:41:28AM +, Mike Silbersack wrote:
> In any case, we can't make any useful comparisons until Dimitar posts the
> source to his test program.
>
> Dimitar, post the source for the test program!
Does your MTA strip attachments?
-> I 1 [text/plain
Simon 'corecode' Schubert wrote:
> to everybody who doesn't believe that: it really generates bad code.
> i've been having severe problems with my tcp and udp stack lately (on a
> i586/mmx machine). guess what, -O2 resulted in code which >>sometimes<<
> generated bad tcp and/or udp checksums (depe
On Thu, Mar 07, 2002 at 08:09:06AM -0600, GB Clark wrote:
> > I've tested it with :
> >
> > cc -O6 -o malloc_test malloc_test.c
>
> That -O6 does not look right from here. Do we support anything over -O2?
>
> And how about some source for malloc_test.c? The fact of running
> something at -O6
On Thu, 7 Mar 2002, Rogier R. Mulhuijzen wrote:
>
> >Once Dimitar posts his test program, we'll be able to generate a more
> >clear picture about what's really happening. Until then, please control
> >the ranting.
>
> Am I the only one who saw that he attached it to his 1st mail?
Apparently no
>Once Dimitar posts his test program, we'll be able to generate a more
>clear picture about what's really happening. Until then, please control
>the ranting.
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*102
alculations, or the results of your
> data. Obviously its your choice :)
Please stop posting this crap.
Dimitar asked a serious question, and I for one would certainly like to be
able to give him a serious answer. Despite what your ranting above would
indicate, ext2's performance shou
ally 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.
> >
On Thu, 7 Mar 2002, cjp wrote:
> 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
On Thu, 7 Mar 2002 16:36:15 +0100 Erik Trulsson <[EMAIL PROTECTED]> wrote:
> > > > I've tested it with :
> > > >
> > > > cc -O6 -o malloc_test malloc_test.c
> > >
> > > That -O6 does not look right from here. Do we support anything over -O2?
> >
> > ISTR that -On is exactly the same for -O2 f
On Thu, Mar 07, 2002 at 04:47:24PM +0200, Peter Pentchev wrote:
> On Thu, Mar 07, 2002 at 08:09:06AM -0600, GB Clark wrote:
> > On Thu, 7 Mar 2002 14:27:59 +0200
> > Dimitar Peikov <[EMAIL PROTECTED]> wrote:
> >
> > > On Thu, 7 Mar 2002 04:01:58 -0800 (PST)
> > > Julian Elischer <[EMAIL PROTECTED
On Thu, Mar 07, 2002 at 09:42:44AM -0500, cjp wrote:
> 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 lo
- Original Message -
> From: "Dimitar Peikov" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> 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
&
use, and all the
c>overhead
c>of assuring its existence at the time of allocation. Much more robust, less
c>prone to abuse.
c>
c>Try it, you'll like it. If you want the nuts and bolts of it, read the source.
c>
c>
c>- Original Message -
c>From: "Dimitar P
istence 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" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, Mar
On Thu, 7 Mar 2002 08:09:06 -0600
GB Clark <[EMAIL PROTECTED]> wrote:
> On Thu, 7 Mar 2002 14:27:59 +0200
> Dimitar Peikov <[EMAIL PROTECTED]> wrote:
>
> > On Thu, 7 Mar 2002 04:01:58 -0800 (PST)
> > Julian Elischer <[EMAIL PROTECTED]> wrote:
> >
> > > he said -stable..
> > >
> > > what are th
On Thu, Mar 07, 2002 at 08:09:06AM -0600, GB Clark wrote:
> On Thu, 7 Mar 2002 14:27:59 +0200
> Dimitar Peikov <[EMAIL PROTECTED]> wrote:
>
> > On Thu, 7 Mar 2002 04:01:58 -0800 (PST)
> > Julian Elischer <[EMAIL PROTECTED]> wrote:
> >
> > > he said -stable..
> > >
> > > what are the malloc opti
On Thu, 7 Mar 2002 14:27:59 +0200
Dimitar Peikov <[EMAIL PROTECTED]> wrote:
> On Thu, 7 Mar 2002 04:01:58 -0800 (PST)
> Julian Elischer <[EMAIL PROTECTED]> wrote:
>
> > he said -stable..
> >
> > what are the malloc options on -stable?
> >
> > maybe we should make sure that they are null
> >
On Thu, 7 Mar 2002 04:01:58 -0800 (PST)
Julian Elischer <[EMAIL PROTECTED]> wrote:
> he said -stable..
>
> what are the malloc options on -stable?
>
> maybe we should make sure that they are null
>
> ln -s ">" /etc/malloc.conf
> (I hope that helps) :)
>
I've tested it with :
cc -O6 -o mall
he said -stable..
what are the malloc options on -stable?
maybe we should make sure that they are null
ln -s ">" /etc/malloc.conf
(I hope that helps) :)
On Thu, 7 Mar 2002, Alfred Perlstein wrote:
> * Dimitar Peikov <[EMAIL PROTECTED]> [020307 00:45] wrote:
> > I start some performance test
* Dimitar Peikov <[EMAIL PROTECTED]> [020307 00:45] wrote:
> 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 granu
On Thu, 7 Mar 2002, Dimitar Peikov wrote:
> 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 swapp
* Dimitar Peikov <[EMAIL PROTECTED]> [020307 00:45] wrote:
> 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 granu
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
40 matches
Mail list logo
