Re: Linux 1.3.90 vasts memory?
Linus Torvalds (torvalds@cs.helsinki.fi)
Wed, 17 Apr 1996 15:03:04 +0300 (EET DST)
>
> In 1.3.90 yet another element was introduced to the mem_map-structure:
>
> In mm.h:
>
> + unsigned long map_nr; /* page->map_nr = page - mem_map
> */
>
> Well, isn't it like that, that in result for every 4k / 8k page another
> 4 bytes are used? (-> 0,1 % of RAM is lost?). Sounds less, but thats
> 4 more pages on the average 16 MB system.
>
> What are the benefits of that? I took a quick look through the code
> and my impression is, that it will mostly save a substraction and
> division (integer) when
>
> - finding a free page
> - allocating a block from a file
>
> Sure, that it is worth this? You could call it an optimization for
> speed vs. memory, but every modern OS an optimization for memory
> is a optimization for speed on the average system, too.
Agreed. However, there are some reasons to keep the "map_nr" entry, even though
we can calculate it at run-time (with a constant division that gcc can optimize
to a multiplication + shift).
I haven't decided which way to go, but having the "mem_map" entry is
potentially a win. Right now it's not used very much, although you didn't
notice that it's used by the "page_address()" inline function that _does_ show
up pretty often. There are some other places that may want to use it in the
future (that do things differently exactly because the field hasn't been
availble).
You're quite right, though - it's a trade-off. I may end up removing the entry
if it turns out that the division is the better thing to do.
Linus