Date: Wed, 21 Mar 2001 10:40:34 -0800 (PST) From: Matt Dillon <dillon@earth.backplane.com> To: Alfred Perlstein <bright@wintelcom.net> Cc: Rik van Riel <riel@conectiva.com.br>, Peter Wemm <peter@netplex.com.au>, "Michael C . Wu" <keichii@iteration.net>, izero@ms26.hinet.net, cross@math.psu.edu, grog@FreeBSD.ORG, fs@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: tuning a VERY heavily (30.0) loaded s cerver Message-ID: <200103211840.f2LIeYA16476@earth.backplane.com> References: <200103211114.f2LBE0h57371@mobile.wemm.org> <Pine.LNX.4.21.0103211328310.9056-100000@imladris.rielhome.conectiva> <20010321095638.H12319@fw.wintelcom.net>
next in thread | previous in thread | raw e-mail | index | archive | help
:* Rik van Riel <riel@conectiva.com.br> [010321 09:51] wrote:
:> On Wed, 21 Mar 2001, Peter Wemm wrote:
:>
:> > Also, 4MB = 1024 pages, at 28 bytes per mapping == 28k per process.
:>
:> 28 bytes/mapping is a LOT. I've implemented an (admittedly
:> not completely architecture-independent) reverse mapping
:> patch for Linux with an overhead of 8 bytes/pte...
:>
:> I wonder how hard/easy would it be to reduce the memory
:> overhead of some of these old Mach data structures in FreeBSD...
:
:"Our" Alan Cox <alc@freebsd.org> and Tor Egge have been trimming
:these structs down for quite some time. Perhaps they should
:look at Linux's system, however last I checked Linux's was
:an order of magnitude less complex which might prohibit that
:simplification in FreeBSD.
:
:If you have suggestions, let's hear them. :)
:
:--
:-Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org]
We've looked at those structures quite a bit. DG and I talked about
it a year or two ago but we came to the conclusion that the extra
linkages in our pv_entry gave us significant performance benefits
during rundowns. Since then Tor has done a lot of cleanup, but
I don't think the analysis has changed much.
typedef struct pv_entry {
pmap_t pv_pmap; /* pmap where mapping lies */
vm_offset_t pv_va; /* virtual address for mapping */
TAILQ_ENTRY(pv_entry) pv_list;
TAILQ_ENTRY(pv_entry) pv_plist;
vm_page_t pv_ptem; /* VM page for pte */
} *pv_entry_t;
pv_pmap
The pmap associated with the pv_entry.
pv_va
The virtual address of the pv_entry in the pmap. Used to quickly
track down the pv_entry associated with a (pmap, vm_page_t, va)
when iterating a pv_list or pv_plist.
pv_list - pv_entry's associated with a vm_page_t.
pv_plist - pv_entry's associated with a pmap
A pmap_entry can be located either through pv_list or through
pv_plist. The kernel chooses which list to iterate through to
find a pv_entry based on which of the two lists has the least number
of elements. One of the two nodes could be removed from the pv_entry
structure (saving 8 bytes) could be removed but at the cost of
performance for certain cases.
If you have a huge number of processes sharing a page of
memory, iterating through pv_plist to locate a mapping is
usually more efficient. If you have fewer processes but full
mappings (e.g. the page table page is full), then iterating
through pv_list is more efficient.
pv_ptem
The vm_page_t associated with a pv_entry. This field is used
to quickly find associate vm_page_t's when we are wiping
whole page tables (e.g. on process exit). It could be
removed, but at significant cost to process exits and
munmap()'s of large areas.
Theoretically we can remove half the structure, but at a
significant cost in performance.
-Matt
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200103211840.f2LIeYA16476>