* BYTE Unix Benchmarks Version 3.6
@ 2002-09-04 22:00 Paolo Ciarrocchi
2002-09-04 22:44 ` Cliff White
` (2 more replies)
0 siblings, 3 replies; 14+ messages in thread
From: Paolo Ciarrocchi @ 2002-09-04 22:00 UTC (permalink / raw)
To: linux-kernel
Hi all,
I've just ran the BYTE Unix Benchmarks Version 3.6 on the 2.4.19 and on the 2.5.33 kernel.
Here it goes the results:
BYTE UNIX Benchmarks (Version 3.11)
System -- Linux localhost.localdomain 2.4.19 #10 Fri Aug 23 20:53:06 BST 2002 i686 unknown
Start Benchmark Run: Wed Sep 4 22:11:32 BST 2002
1 interactive users.
Dhrystone 2 without register variables 1499020.6 lps (10 secs, 6 samples)
Dhrystone 2 using register variables 1501168.4 lps (10 secs, 6 samples)
Arithmetic Test (type = arithoh) 3598100.4 lps (10 secs, 6 samples)
Arithmetic Test (type = register) 201521.0 lps (10 secs, 6 samples)
Arithmetic Test (type = short) 190245.9 lps (10 secs, 6 samples)
Arithmetic Test (type = int) 201904.5 lps (10 secs, 6 samples)
Arithmetic Test (type = long) 201906.4 lps (10 secs, 6 samples)
Arithmetic Test (type = float) 210562.7 lps (10 secs, 6 samples)
Arithmetic Test (type = double) 210385.9 lps (10 secs, 6 samples)
System Call Overhead Test 407402.6 lps (10 secs, 6 samples)
Pipe Throughput Test 476268.6 lps (10 secs, 6 samples)
Pipe-based Context Switching Test 218969.9 lps (10 secs, 6 samples)
Process Creation Test 9078.6 lps (10 secs, 6 samples)
Execl Throughput Test 998.0 lps (9 secs, 6 samples)
File Read (10 seconds) 1571652.0 KBps (10 secs, 6 samples)
File Write (10 seconds) 109237.0 KBps (10 secs, 6 samples)
File Copy (10 seconds) 24329.0 KBps (10 secs, 6 samples)
File Read (30 seconds) 1562505.0 KBps (30 secs, 6 samples)
File Write (30 seconds) 113152.0 KBps (30 secs, 6 samples)
File Copy (30 seconds) 14334.0 KBps (30 secs, 6 samples)
C Compiler Test 470.9 lpm (60 secs, 3 samples)
Shell scripts (1 concurrent) 980.4 lpm (60 secs, 3 samples)
Shell scripts (2 concurrent) 544.1 lpm (60 secs, 3 samples)
Shell scripts (4 concurrent) 287.0 lpm (60 secs, 3 samples)
Shell scripts (8 concurrent) 147.0 lpm (60 secs, 3 samples)
Dc: sqrt(2) to 99 decimal places 42311.6 lpm (60 secs, 6 samples)
Recursion Test--Tower of Hanoi 18915.4 lps (10 secs, 6 samples)
INDEX VALUES
TEST BASELINE RESULT INDEX
Arithmetic Test (type = double) 2541.7 210385.9 82.8
Dhrystone 2 without register variables 22366.3 1499020.6 67.0
Execl Throughput Test 16.5 998.0 60.5
File Copy (30 seconds) 179.0 14334.0 80.1
Pipe-based Context Switching Test 1318.5 218969.9 166.1
Shell scripts (8 concurrent) 4.0 147.0 36.8
=========
SUM of 6 items 493.2
AVERAGE 82.2
sh pgms/report.sh results/log > results/report
sh pgms/index.sh pgms/index.base results/log >> results/report
cat results/report
BYTE UNIX Benchmarks (Version 3.11)
System -- Linux localhost.localdomain 2.5.33 #32 Tue Sep 3 22:18:19 BST 2002 i686 unknown
Start Benchmark Run: Wed Sep 4 20:46:31 BST 2002
1 interactive users.
Dhrystone 2 without register variables 1488327.9 lps (10 secs, 6 samples)
Dhrystone 2 using register variables 1488265.3 lps (10 secs, 6 samples)
Arithmetic Test (type = arithoh) 3435944.6 lps (10 secs, 6 samples)
Arithmetic Test (type = register) 197870.4 lps (10 secs, 6 samples)
Arithmetic Test (type = short) 145140.8 lps (10 secs, 6 samples)
Arithmetic Test (type = int) 104440.5 lps (10 secs, 6 samples)
Arithmetic Test (type = long) 177757.4 lps (10 secs, 6 samples)
Arithmetic Test (type = float) 208476.4 lps (10 secs, 6 samples)
Arithmetic Test (type = double) 208443.3 lps (10 secs, 6 samples)
System Call Overhead Test 397276.7 lps (10 secs, 6 samples)
Pipe Throughput Test 434561.9 lps (10 secs, 6 samples)
Pipe-based Context Switching Test 148653.5 lps (10 secs, 6 samples)
Process Creation Test 5422.1 lps (10 secs, 6 samples)
Execl Throughput Test 771.6 lps (10 secs, 6 samples)
File Read (10 seconds) 1553289.0 KBps (10 secs, 6 samples)
File Write (10 seconds) 132002.0 KBps (10 secs, 6 samples)
File Copy (10 seconds) 17994.0 KBps (10 secs, 6 samples)
File Read (30 seconds) 1540682.0 KBps (30 secs, 6 samples)
File Write (30 seconds) 137781.0 KBps (30 secs, 6 samples)
File Copy (30 seconds) 11460.0 KBps (30 secs, 6 samples)
C Compiler Test 450.9 lpm (60 secs, 3 samples)
Shell scripts (1 concurrent) 876.7 lpm (60 secs, 3 samples)
Shell scripts (2 concurrent) 480.3 lpm (60 secs, 3 samples)
Shell scripts (4 concurrent) 251.0 lpm (60 secs, 3 samples)
Shell scripts (8 concurrent) 126.0 lpm (60 secs, 3 samples)
Dc: sqrt(2) to 99 decimal places 33530.4 lpm (60 secs, 6 samples)
Recursion Test--Tower of Hanoi 18514.3 lps (10 secs, 6 samples)
INDEX VALUES
TEST BASELINE RESULT INDEX
Arithmetic Test (type = double) 2541.7 208443.3 82.0
Dhrystone 2 without register variables 22366.3 1488327.9 66.5
Execl Throughput Test 16.5 771.6 46.8
File Copy (30 seconds) 179.0 11460.0 64.0
Pipe-based Context Switching Test 1318.5 148653.5 112.7
Shell scripts (8 concurrent) 4.0 126.0 31.5
=========
SUM of 6 items 403.6
AVERAGE 67.3
Comments?
--
Get your free email from www.linuxmail.org
Powered by Outblaze
^ permalink raw reply [flat|nested] 14+ messages in thread* Re: BYTE Unix Benchmarks Version 3.6
2002-09-04 22:00 BYTE Unix Benchmarks Version 3.6 Paolo Ciarrocchi
@ 2002-09-04 22:44 ` Cliff White
2002-09-04 23:57 ` Andrea Arcangeli
2002-09-05 13:48 ` side-by-side " bert hubert
2 siblings, 0 replies; 14+ messages in thread
From: Cliff White @ 2002-09-04 22:44 UTC (permalink / raw)
To: Paolo Ciarrocchi; +Cc: linux-kernel, cliffw
> Hi all,
> I've just ran the BYTE Unix Benchmarks Version 3.6 on the 2.4.19 and on the 2.5.33 kernel.
> Here it goes the results:
>
snipped:
Always useful to compare. I think the data from STP show something simular.
I've pulled some reports, rather than send a huge email, here are the URL's
(btw STP runs v4.0.1 UNIXbench)
runs made on 2-CPU platform
2.4.19: http://khack.osdl.org/stp/3877/results/report
2.5.33: http://khack.osdl.org/stp/4928/results/report
Another compare...why does pre5 appear a little worse than pre4 ?
2.4.20-pre5: http://khack.osdl.org/stp/4836/results/report
2.4.20-pre4: http://khack.osdl.org/stp/4581/results/report
cliffw
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: BYTE Unix Benchmarks Version 3.6
2002-09-04 22:00 BYTE Unix Benchmarks Version 3.6 Paolo Ciarrocchi
2002-09-04 22:44 ` Cliff White
@ 2002-09-04 23:57 ` Andrea Arcangeli
2002-09-05 13:48 ` side-by-side " bert hubert
2 siblings, 0 replies; 14+ messages in thread
From: Andrea Arcangeli @ 2002-09-04 23:57 UTC (permalink / raw)
To: Paolo Ciarrocchi; +Cc: linux-kernel
On Thu, Sep 05, 2002 at 06:00:55AM +0800, Paolo Ciarrocchi wrote:
> Hi all,
> I've just ran the BYTE Unix Benchmarks Version 3.6 on the 2.4.19 and on the 2.5.33 kernel.
> Here it goes the results:
can you make a run on 2.4.20pre5aa1 too? thanks,
> Comments?
I'm just guessing but I think part of the global regression in most
numbers is most due the increased HZ and rmap.
Andrea
^ permalink raw reply [flat|nested] 14+ messages in thread
* side-by-side Re: BYTE Unix Benchmarks Version 3.6
2002-09-04 22:00 BYTE Unix Benchmarks Version 3.6 Paolo Ciarrocchi
2002-09-04 22:44 ` Cliff White
2002-09-04 23:57 ` Andrea Arcangeli
@ 2002-09-05 13:48 ` bert hubert
2002-09-05 15:11 ` venom
2002-09-06 3:23 ` Daniel Phillips
2 siblings, 2 replies; 14+ messages in thread
From: bert hubert @ 2002-09-05 13:48 UTC (permalink / raw)
To: Paolo Ciarrocchi; +Cc: linux-kernel
Side-by-side with some marked changes highlighted:
2.4.19 2.5.33
-----------------------------------------------------------------------
Dhrystone 2 without register variable 1499020.6 lps 1488327.9 lps
Dhrystone 2 using register variables 1501168.4 lps 1488265.3 lps
Arithmetic Test (type = arithoh) 3598100.4 lps 3435944.6 lps
Arithmetic Test (type = register) 201521.0 lps 197870.4 lps
Arithmetic Test (type = short) 190245.9 lps 145140.8 lps
Arithmetic Test (type = int) 201904.5 lps 104440.5 lps
Arithmetic Test (type = long) 201906.4 lps 177757.4 lps
Arithmetic Test (type = float) 210562.7 lps 208476.4 lps
Arithmetic Test (type = double) 210385.9 lps 208443.3 lps
System Call Overhead Test 407402.6 lps 397276.7 lps
>Pipe Throughput Test 476268.6 lps 434561.9 lps
>Pipe-based Context Switching Test 218969.9 lps 148653.5 lps
>Process Creation Test 9078.6 lps 5422.1 lps
Execl Throughput Test 998.0 lps 771.6 lps
File Read (10 seconds) 1571652.0 KBps 1553289.0 KBps
File Write (10 seconds) 109237.0 KBps 132002.0 KBps
>File Copy (10 seconds) 24329.0 KBps 17994.0 KBps
File Read (30 seconds) 1562505.0 KBps 1540682.0 KBps
File Write (30 seconds) 113152.0 KBps 137781.0 KBps
File Copy (30 seconds) 14334.0 KBps 11460.0 KBps
C Compiler Test 470.9 lpm 450.9 lpm
Shell scripts (1 concurrent) 980.4 lpm 876.7 lpm
Shell scripts (2 concurrent) 544.1 lpm 480.3 lpm
Shell scripts (4 concurrent) 287.0 lpm 251.0 lpm
Shell scripts (8 concurrent) 147.0 lpm 126.0 lpm
>Dc: sqrt(2) to 99 decimal places 42311.6 lpm 33530.4 lpm
Recursion Test--Tower of Hanoi 18915.4 lps 18514.3 lps
INDEX VALUES 2.4.19 2.5
TEST INDEX INDEX
Arithmetic Test (type = double) 82.8 82.0
Dhrystone 2 without register variables 67.0 66.5
Execl Throughput Test 60.5 46.8
File Copy (30 seconds) 80.1 64.0
Pipe-based Context Switching Test 166.1 112.7
Shell scripts (8 concurrent) 36.8 31.5
========= =========
SUM of 6 items 493.2 403.6
AVERAGE 82.2 67.3
--
http://www.PowerDNS.com Versatile DNS Software & Services
http://www.tk the dot in .tk
http://lartc.org Linux Advanced Routing & Traffic Control HOWTO
^ permalink raw reply [flat|nested] 14+ messages in thread* Re: side-by-side Re: BYTE Unix Benchmarks Version 3.6
2002-09-05 13:48 ` side-by-side " bert hubert
@ 2002-09-05 15:11 ` venom
2002-09-06 3:23 ` Daniel Phillips
1 sibling, 0 replies; 14+ messages in thread
From: venom @ 2002-09-05 15:11 UTC (permalink / raw)
To: bert hubert; +Cc: Paolo Ciarrocchi, linux-kernel
I usually run byte bench regularly with every new kernel, so I see some
strange results here.
>From your numbers, I would say you are using a PIII 600/900 Mhz (more or
less). It is not an AMD AThlon or a PIV, since float and double are too
slow, not it is a K6 because they are too fast.
On Thu, 5 Sep 2002, bert hubert wrote:
> Date: Thu, 5 Sep 2002 15:48:30 +0200
> From: bert hubert <ahu@ds9a.nl>
> To: Paolo Ciarrocchi <ciarrocchi@linuxmail.org>
> Cc: linux-kernel@vger.kernel.org
> Subject: side-by-side Re: BYTE Unix Benchmarks Version 3.6
>
> Side-by-side with some marked changes highlighted:
>
> 2.4.19 2.5.33
> -----------------------------------------------------------------------
> Dhrystone 2 without register variable 1499020.6 lps 1488327.9 lps
> Dhrystone 2 using register variables 1501168.4 lps 1488265.3 lps
> Arithmetic Test (type = arithoh) 3598100.4 lps 3435944.6 lps
this could vary a little
> Arithmetic Test (type = register) 201521.0 lps 197870.4 lps
> Arithmetic Test (type = short) 190245.9 lps 145140.8 lps
the difference should never be so big
> Arithmetic Test (type = int) 201904.5 lps 104440.5 lps
the difference should never be so big
> Arithmetic Test (type = long) 201906.4 lps 177757.4 lps
the difference should never be so big
seeing this I think you had something running in background using your CPU
while you where running int tests. if you loock at bm/results/log
(log.accum if you did some other run recently)
should find lines like:
Arithmetic Test (type = int)|10.0|lps|227163.1|227158.7|6
that is a little more interesting if you are under load.
> Arithmetic Test (type = float) 210562.7 lps 208476.4 lps
> Arithmetic Test (type = double) 210385.9 lps 208443.3 lps
> System Call Overhead Test 407402.6 lps 397276.7 lps
> >Pipe Throughput Test 476268.6 lps 434561.9 lps
> >Pipe-based Context Switching Test 218969.9 lps 148653.5 lps
this could vary because of a lot of factors, starting from a bad page
colouring going to sendmail activity.
> >Process Creation Test 9078.6 lps 5422.1 lps
> Execl Throughput Test 998.0 lps 771.6 lps
this is interesting, but seeing previous results about int and short,
I am curious about your real load. I am quite curious if with 2.5 you are
using kernel preemption.
> File Read (10 seconds) 1571652.0 KBps 1553289.0 KBps
> File Write (10 seconds) 109237.0 KBps 132002.0 KBps
> >File Copy (10 seconds) 24329.0 KBps 17994.0 KBps
> File Read (30 seconds) 1562505.0 KBps 1540682.0 KBps
> File Write (30 seconds) 113152.0 KBps 137781.0 KBps
> File Copy (30 seconds) 14334.0 KBps 11460.0 KBps
I saw the save with IDE disks... again, are you using kernel preemption?
> C Compiler Test 470.9 lpm 450.9 lpm
> Shell scripts (1 concurrent) 980.4 lpm 876.7 lpm
> Shell scripts (2 concurrent) 544.1 lpm 480.3 lpm
> Shell scripts (4 concurrent) 287.0 lpm 251.0 lpm
> Shell scripts (8 concurrent) 147.0 lpm 126.0 lpm
In my tests generally shell scripts are faster with 2.5 kernel.
> >Dc: sqrt(2) to 99 decimal places 42311.6 lpm 33530.4 lpm
> Recursion Test--Tower of Hanoi 18915.4 lps 18514.3 lps
>
>
> INDEX VALUES 2.4.19 2.5
> TEST INDEX INDEX
>
> Arithmetic Test (type = double) 82.8 82.0
> Dhrystone 2 without register variables 67.0 66.5
> Execl Throughput Test 60.5 46.8
> File Copy (30 seconds) 80.1 64.0
> Pipe-based Context Switching Test 166.1 112.7
> Shell scripts (8 concurrent) 36.8 31.5
> ========= =========
> SUM of 6 items 493.2 403.6
> AVERAGE 82.2 67.3
>
Luigi
> --
> http://www.PowerDNS.com Versatile DNS Software & Services
> http://www.tk the dot in .tk
> http://lartc.org Linux Advanced Routing & Traffic Control HOWTO
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: side-by-side Re: BYTE Unix Benchmarks Version 3.6
2002-09-05 13:48 ` side-by-side " bert hubert
2002-09-05 15:11 ` venom
@ 2002-09-06 3:23 ` Daniel Phillips
2002-09-06 3:34 ` Calculating kernel logical address Imran Badr
2002-09-06 7:09 ` side-by-side Re: BYTE Unix Benchmarks Version 3.6 bert hubert
1 sibling, 2 replies; 14+ messages in thread
From: Daniel Phillips @ 2002-09-06 3:23 UTC (permalink / raw)
To: bert hubert, Paolo Ciarrocchi; +Cc: linux-kernel
On Thursday 05 September 2002 15:48, bert hubert wrote:
> Arithmetic Test (type = arithoh) 3598100.4 lps 3435944.6 lps
> Arithmetic Test (type = register) 201521.0 lps 197870.4 lps
> Arithmetic Test (type = short) 190245.9 lps 145140.8 lps
> Arithmetic Test (type = int) 201904.5 lps 104440.5 lps
> Arithmetic Test (type = long) 201906.4 lps 177757.4 lps
> Arithmetic Test (type = float) 210562.7 lps 208476.4 lps
> Arithmetic Test (type = double) 210385.9 lps 208443.3 lps
What kind of arithmetic is this? Why on earth would arithmetic vary
from one kernel to another?
--
Daniel
^ permalink raw reply [flat|nested] 14+ messages in thread
* Calculating kernel logical address ..
2002-09-06 3:23 ` Daniel Phillips
@ 2002-09-06 3:34 ` Imran Badr
2002-09-07 1:44 ` Daniel Phillips
2002-09-06 7:09 ` side-by-side Re: BYTE Unix Benchmarks Version 3.6 bert hubert
1 sibling, 1 reply; 14+ messages in thread
From: Imran Badr @ 2002-09-06 3:34 UTC (permalink / raw)
To: linux-kernel
Hi,
I need help to correctly calculate kernel logical address for a user pointer
which I mmaped from device driver. In mmap() file operation, I allocate some
memory using kmalloc() and call :
remap_page_range(vma->vm_start,
virt_to_phys((void *)(Uint32)kmalloc_buffer),
size,
PAGE_SHARED);
after reserving all pages and doing some other stuff. Now when I get a user
pointer and I need to calculate correspoding kernel logical address, I use
following code:
adr = user_address;
pgd_offset(current->mm, adr);
if (!pgd_none(*pgd)) {
pmd = pmd_offset(pgd, adr);
if (!pmd_none(*pmd)) {
ptep = pte_offset(pmd, adr);
pte = *ptep;
if(pte_present(pte)) {
kaddr = (unsigned long) page_address(pte_page(pte));
kaddr |= (adr & (PAGE_SIZE - 1));
}
}
}
Will this code always give me correct kernel logical address?
I will really appreciate any guidance.
Thanks,
Imran.
^ permalink raw reply [flat|nested] 14+ messages in thread* Re: Calculating kernel logical address ..
2002-09-06 3:34 ` Calculating kernel logical address Imran Badr
@ 2002-09-07 1:44 ` Daniel Phillips
2002-09-08 0:01 ` David S. Miller
0 siblings, 1 reply; 14+ messages in thread
From: Daniel Phillips @ 2002-09-07 1:44 UTC (permalink / raw)
To: imran.badr, linux-kernel
On Friday 06 September 2002 05:34, Imran Badr wrote:
> if (!pgd_none(*pgd)) {
> pmd = pmd_offset(pgd, adr);
> if (!pmd_none(*pmd)) {
> ptep = pte_offset(pmd, adr);
> pte = *ptep;
> if(pte_present(pte)) {
> kaddr = (unsigned long) page_address(pte_page(pte));
> kaddr |= (adr & (PAGE_SIZE - 1));
> }
> }
> }
>
> Will this code always give me correct kernel logical address?
>
> I will really appreciate any guidance.
It looks good to me. Note that somebody has added some new voodoo in 2.5
so that page table pages can be in highmem, with the result that the above
code won't work in 2.5, whether or not highmem is configured.
--
Daniel
^ permalink raw reply [flat|nested] 14+ messages in thread* Re: Calculating kernel logical address ..
2002-09-07 1:44 ` Daniel Phillips
@ 2002-09-08 0:01 ` David S. Miller
2002-09-08 18:44 ` Daniel Phillips
0 siblings, 1 reply; 14+ messages in thread
From: David S. Miller @ 2002-09-08 0:01 UTC (permalink / raw)
To: phillips; +Cc: imran.badr, linux-kernel
From: Daniel Phillips <phillips@arcor.de>
Date: Sat, 7 Sep 2002 03:44:53 +0200
It looks good to me. Note that somebody has added some new voodoo in 2.5
so that page table pages can be in highmem, with the result that the above
code won't work in 2.5, whether or not highmem is configured.
The example given won't work for kernel text/data addresses on a few
platforms (sparc64 is one). And in fact on MIPS the KSEG0 pages lack
any page tables.
There are only three things one can portably obtain a physical address
of:
1) A user address, for a known MM
2) a kmalloc/get_free_page kernel page
3) A vmalloc page
For anything else you're in non-portablt land, including and
in partiular:
1) kernel stack addresses
2) addresses within the main kernel image text/data/bss
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Calculating kernel logical address ..
2002-09-08 0:01 ` David S. Miller
@ 2002-09-08 18:44 ` Daniel Phillips
2002-09-09 5:00 ` David S. Miller
0 siblings, 1 reply; 14+ messages in thread
From: Daniel Phillips @ 2002-09-08 18:44 UTC (permalink / raw)
To: David S. Miller; +Cc: imran.badr, linux-kernel
On Sunday 08 September 2002 02:01, David S. Miller wrote:
> From: Daniel Phillips <phillips@arcor.de>
> Date: Sat, 7 Sep 2002 03:44:53 +0200
>
> It looks good to me. Note that somebody has added some new voodoo in 2.5
> so that page table pages can be in highmem, with the result that the above
> code won't work in 2.5, whether or not highmem is configured.
>
> The example given won't work for kernel text/data addresses on a few
> platforms (sparc64 is one). And in fact on MIPS the KSEG0 pages lack
> any page tables.
>
> There are only three things one can portably obtain a physical address
> of:
>
> 1) A user address, for a known MM
>
> 2) a kmalloc/get_free_page kernel page
>
> 3) A vmalloc page
Actually, he was trying to obtain a kernel virtual address, which
presents its own difficulties, particularly with respect to highmem.
> For anything else you're in non-portablt land, including and
> in partiular:
>
> 1) kernel stack addresses
Could you elaborate on what bad things happen here?
> 2) addresses within the main kernel image text/data/bss
Yep. MIPS's KSEG0 (a stupid design if there ever was one) and i386 large
kernel image pages are just two examples of wrinkles that would need to
be handled. The general principle is: mappings in the kernel's virtual
address space are not maintained by the faulting mechanism, they are
maintained 'by hand'; and the cross-platform N-level page tree is defined
only for addresses that can fault.
Where the page tree does define a mapping to physical memory, obviously
only a physical address may be obtained that way, and due to highmem,
this address may not be mapped into the kernel's virtual address range,
in which case a further kmapping step has to be performed to obtain a
kernel-usable address, subject to bizarre rules that tend to change on
a weekly basis.
Somebody needs to write a book about this ;-)
--
Daniel
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Calculating kernel logical address ..
2002-09-08 18:44 ` Daniel Phillips
@ 2002-09-09 5:00 ` David S. Miller
2002-09-09 5:17 ` Daniel Phillips
0 siblings, 1 reply; 14+ messages in thread
From: David S. Miller @ 2002-09-09 5:00 UTC (permalink / raw)
To: phillips; +Cc: imran.badr, linux-kernel
From: Daniel Phillips <phillips@arcor.de>
Date: Sun, 8 Sep 2002 20:44:17 +0200
> For anything else you're in non-portablt land, including and
> in partiular:
>
> 1) kernel stack addresses
Could you elaborate on what bad things happen here?
Kernel stack allocation is defined per-architecture. On
sun4c sparc systems, we carve virtual pages out from the kernel
address space and hard map them into the TLB by hand.
> 2) addresses within the main kernel image text/data/bss
Yep. MIPS's KSEG0 (a stupid design if there ever was one)
Actually, KSEG0 the most Linux friendly design in the world
particularly in 64-bit mode. There is no need to have page tables at
all for the main kernel physical memory map. It would shave a lot of
code from the sparc64 TLB miss handlers if I didn't have to handle
PAGE_OFFSET pages, for example.
Alpha does something akin to KSEG0 as well.
I pine constantly for it appearing some day on a future UltraSPARC
revision :-)
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Calculating kernel logical address ..
2002-09-09 5:00 ` David S. Miller
@ 2002-09-09 5:17 ` Daniel Phillips
2002-09-09 5:28 ` David S. Miller
0 siblings, 1 reply; 14+ messages in thread
From: Daniel Phillips @ 2002-09-09 5:17 UTC (permalink / raw)
To: David S. Miller; +Cc: imran.badr, linux-kernel
On Monday 09 September 2002 07:00, David S. Miller wrote:
> > 2) addresses within the main kernel image text/data/bss
>
> Yep. MIPS's KSEG0 (a stupid design if there ever was one)
>
> Actually, KSEG0 the most Linux friendly design in the world
> particularly in 64-bit mode.
That's easy to say until you try and work with it (I assume you have,
and forgot). Just try to do a 3G/1G split on it, for example.
> I pine constantly for it appearing some day on a future UltraSPARC
> revision :-)
Don't wish too hard, you might get it ;-)
--
Daniel
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Calculating kernel logical address ..
2002-09-09 5:17 ` Daniel Phillips
@ 2002-09-09 5:28 ` David S. Miller
0 siblings, 0 replies; 14+ messages in thread
From: David S. Miller @ 2002-09-09 5:28 UTC (permalink / raw)
To: phillips; +Cc: imran.badr, linux-kernel
From: Daniel Phillips <phillips@arcor.de>
Date: Mon, 9 Sep 2002 07:17:30 +0200
On Monday 09 September 2002 07:00, David S. Miller wrote:
> Actually, KSEG0 the most Linux friendly design in the world
> particularly in 64-bit mode.
That's easy to say until you try and work with it (I assume you have,
and forgot). Just try to do a 3G/1G split on it, for example.
Maybe you missed the "64-bit mode" part of what I said. :-)
In 64-bit mode there is no need to do any kind of split.
You just use the KSEG mapping with full cache coherency for
all of physical memory as the PAGE_OFFSET area.
I forget if it was KSEG0 or some other number, but I know it
works.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: side-by-side Re: BYTE Unix Benchmarks Version 3.6
2002-09-06 3:23 ` Daniel Phillips
2002-09-06 3:34 ` Calculating kernel logical address Imran Badr
@ 2002-09-06 7:09 ` bert hubert
1 sibling, 0 replies; 14+ messages in thread
From: bert hubert @ 2002-09-06 7:09 UTC (permalink / raw)
To: Daniel Phillips; +Cc: Paolo Ciarrocchi, linux-kernel
On Fri, Sep 06, 2002 at 05:23:48AM +0200, Daniel Phillips wrote:
> On Thursday 05 September 2002 15:48, bert hubert wrote:
> > Arithmetic Test (type = arithoh) 3598100.4 lps 3435944.6 lps
> > Arithmetic Test (type = register) 201521.0 lps 197870.4 lps
> > Arithmetic Test (type = short) 190245.9 lps 145140.8 lps
> > Arithmetic Test (type = int) 201904.5 lps 104440.5 lps
> > Arithmetic Test (type = long) 201906.4 lps 177757.4 lps
> > Arithmetic Test (type = float) 210562.7 lps 208476.4 lps
> > Arithmetic Test (type = double) 210385.9 lps 208443.3 lps
>
> What kind of arithmetic is this? Why on earth would arithmetic vary
> from one kernel to another?
I wasn't involved in this benchmark, I just reformatted the results.
However, it might be that this benchmark is a tad braindead and 'suffers'
from far better timing resolution because of HZ=1000. I'm unsure. I saw that
this benchmark used something like a Sparcstation 5 as a reference platform,
so maybe it is not geared for today's processors.
Regards,
bert hubert
--
http://www.PowerDNS.com Versatile DNS Software & Services
http://www.tk the dot in .tk
http://lartc.org Linux Advanced Routing & Traffic Control HOWTO
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2002-09-09 5:31 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2002-09-04 22:00 BYTE Unix Benchmarks Version 3.6 Paolo Ciarrocchi
2002-09-04 22:44 ` Cliff White
2002-09-04 23:57 ` Andrea Arcangeli
2002-09-05 13:48 ` side-by-side " bert hubert
2002-09-05 15:11 ` venom
2002-09-06 3:23 ` Daniel Phillips
2002-09-06 3:34 ` Calculating kernel logical address Imran Badr
2002-09-07 1:44 ` Daniel Phillips
2002-09-08 0:01 ` David S. Miller
2002-09-08 18:44 ` Daniel Phillips
2002-09-09 5:00 ` David S. Miller
2002-09-09 5:17 ` Daniel Phillips
2002-09-09 5:28 ` David S. Miller
2002-09-06 7:09 ` side-by-side Re: BYTE Unix Benchmarks Version 3.6 bert hubert
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.