lkml.org 
[lkml]   [1999]   [Dec]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Subjectsizeof(struct page) from 44 to 32 bytes for 32-bit <256MB
Date
From
Has anyone thought/tried/benchmarked the following optimisation for
32-bit systems with less than 256 MB physical RAM? Currently,
struct page takes up 40 or 48 bytes (2.2 v. 2.3) on such systems.
That can be reduced by at least 10 bytes (for 2.3) which brings the
next_hash field into the first cache line (and flags can fit in there
too). That means that a lot of uses of struct page only use a single
cache line per touched struct page instead of two.

The idea is to replace the various struct page pointers (4 bytes) with
a 2 byte page frame number which can then cope with 64K x 4K = 256MB
physical RAM. The relevant pointers are the struct page * fields (two
each hidden in struct list_head list and lru and one in next_hash
along with a reduction of unsigned long flags to 16 bits if flags is
wanted in the first cache line instead of just next_hash. Intead of
following pointers, you just use mem_map[new_pfn] and the changes
should only affect a few places in mm/*.c.

Since this involves modifying the supposedly architecture independent
mm code and also only applies to machines with < 256 MB RAM it could
be considered a bit nasty but if it improved performance enough, it
may be worth having as a "compile your kernel with
CONFIG_OPIMIZE_32BIT_UNDER_256MB if you wish" option. (It saves a few
KB by having a smaller mem_map array too but perhaps that's less
likely to affect performance).

It could even be done by modifying struct page to use pfns always for
every architecture which would make it rather cleaner since you could
then optimize for other architectures too. For example, Alpha and
sparc64 could use a 32-bit pfn instead of a 64-bit pointer in all
those places which would again save cacheline space.

--Malcolm

--
Malcolm Beattie <mbeattie@sable.ox.ac.uk>
Unix Systems Programmer
Oxford University Computing Services

-
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:55    [W:0.028 / U:0.448 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site