lkml.org 
[lkml]   [1999]   [Jan]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: tiny patch, reduces kernel memory usage (memory_save patch)
On Fri, 15 Jan 1999, Andrea Arcangeli wrote:

>On Wed, 13 Jan 1999, Max wrote:
>
>> 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
>
>Convinced (but note, I don't think it's an improvement, but it really
>seems that the overhead is zero and we save some bit of memory at the same
>time).

Of course. I was not trying to show it substantially increased performance,
as I noticed by myself that it didn't.
After all I named the patch as 'memory_save'.

> Next arca patches will have map_nr killed too. Thanks Max.

Wow.

Now, bouncing to the other side (i.e. talking against my own idea *scream*)
I noticed that some architectures use p->map_nr in the arch/ tree of the code.
In particular sparc64 has a lot of references to it. I wrote a patch to modify
them to (p - mem_map) as well as on all other architectures --- which is really
simple anyway --- but I don't know wether it may hurt performance on some of
the non-Intel archs.

But maybe i386 does the same, hiding it in some macros...
so I may be completely wrong.


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/

\
 
 \ /
  Last update: 2005-03-22 13:49    [W:0.115 / U:0.108 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site