From: Malcolm Beattie <mbeattie@sable.ox.ac.uk>
To: linux-mm@kvack.org
Subject: sizeof(struct page) from 44 to 32 bytes for 32-bit <256MB
Date: Wed, 8 Dec 1999 17:42:49 +0000 (GMT) [thread overview]
Message-ID: <E11vl73-00012G-00@sable.ox.ac.uk> (raw)
I sent this to linux-kernel a week ago but got zero responses so I
thought I'd try sending it to linux-mm. Apologies to anyone who
reads this twice.
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, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/
next reply other threads:[~1999-12-08 17:42 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
1999-12-08 17:42 Malcolm Beattie [this message]
1999-12-08 17:54 ` Andrea Arcangeli
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=E11vl73-00012G-00@sable.ox.ac.uk \
--to=mbeattie@sable.ox.ac.uk \
--cc=linux-mm@kvack.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox