>On Mon, 11 Jan 1999, Max wrote:
>
>> Even on a 16M box, you are setting up an array of 4096 longs just to cache the
>> result of p->map_nr = p - mem_map; and that's 16k.
>
>I care to optimize the high memory case.
>
>> Also, the kernel compile test I did actually resulted in marginally *better*
>> performance.
>
>The test you done is useless. And btw if you really want to benchmark the
>thing, you must do that on an high memory machine not with 16Mbyte.
Ok, so I grabbed a 128Mb PentiumII 266MHz and tested on it.
The results are:
(still kernel compile, suggest something else and I'll try too)
kernel: memory (code,reserved,data,init): compile time:
stock 2.2.0-pre7 768k,404k,1744k,28k 5m 29s 75
2.2.0-pre7 + my patch 768k,404k,1488k,28k 5m 29s 25
So I really say there is no visible performance change,
I just gained 256k of RAM.
>Andrea Arcangeli
>
P.S. I also looked at the way gcc optimizes this:
mem_map_t *a, *b;
unsigned long map_nr = a - b;
It uses the multiplication trick Colin Plumb explained to divide by
sizeof(mem_map_t), but combines a few leal, addl, sarl, sall instaed
of using an imull.
I checked on a 386 manual (yep, not a pentium or pentiumII manual, true)
for the cycles they need, and they resulted quite faster both than
imull and idivl.
P.S. The memory usage peak during compile was 60Mb.
Massimiliano Ghilardi
----------------------------------------------------------------
| I have yet to meet a person who had a bad experience of Linux. |
| Most have never had an experience. |
----------------------------------------------------------------
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/