lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4B3CD221.1090402@tmr.com>
Date:	Thu, 31 Dec 2009 11:32:33 -0500
From:	Bill Davidsen <davidsen@....com>
To:	Boaz Harrosh <bharrosh@...asas.com>
CC:	Linux Kernel mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Ubuntu 32-bit, 32-bit PAE, 64-bit Kernel Benchmarks

Boaz Harrosh wrote:
> On 12/31/2009 04:49 AM, Bill Davidsen wrote:
>> Yuhong Bao wrote:
>>> Given that Linus was once talking about the performance penalties of PAE and HIGHMEM64G, perhaps you'd find these benchmarks done by Phoronix of interest:
>>> http://www.phoronix.com/scan.php?page=article&item=ubuntu_32_pae
>>>
>> I find these tests mirror my own experience with PAE, the benefit of having the 
>> nx hardware enabled justifies the few percent drop in performance I was able to 
>> find.
>>
>> I find the huge gain in web service hard to believe without a hint why a 64 bit 
>> CPU would be 15x faster. The disk, memory, and network wouldn't be faster, and 
>> the CPU intensive tests weren't significantly faster, so unless the systems were 
>> tuned differently where's the gain? Same feeling about the TP test, an order of 
>> magnitude faster on a test running the same application on the same hardware is 
>> hard to buy without an explanation.
>>
> 
> Why? simple, Memory. This system must have lots of memory (see the HIGHMEM64G) so
> lots of IO must be bouncing on a 32bit system, where in 64bit it is copy-less.
> 
Did you miss the hardware configuration? It was run on a laptop with 4GB and two 
little laptop drives. And there was no serious difference between the non-PAE 
(sees 3GB) and PAE (sees 4GB) performance. Clearly there's little enough memory 
to address in any mode.

> Just my guess, but I'm not surprised.
> 
Eight thousand pages/sec out of a laptop with 5400 rpm drives doesn't surprise 
you? Even if every page were copied to somewhere else the speed of the disk and 
network are still 1000 times slower. I haven't found details on this "test" but 
I'm guessing that the pages are all in memory so the disk is only used once, 
maybe even the same page being read each time, and if the client is on the same 
machine the "network" is loopback. Not representative of much of anything in the 
general case, that.

>> The only obvious source I can think of is running the test load at 100Mbit on
>> one test and Gbit on another, because I saw an early network driver do just that
>> in negotiations with a switch.
>>


-- 
Bill Davidsen <davidsen@....com>
   "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ