Date: Wed, 21 Mar 2001 20:49:55 +0100 From: Poul-Henning Kamp <phk@critter.freebsd.dk> To: doc@freebsd.org Subject: Re: tuning a VERY heavily (30.0) loaded s cerver Message-ID: <87847.985204195@critter> In-Reply-To: Your message of "Wed, 21 Mar 2001 10:40:34 PST." <200103211840.f2LIeYA16476@earth.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Quick, somebody turn this into a pv_entry(9)
In message <200103211840.f2LIeYA16476@earth.backplane.com>, Matt Dillon writes:
> 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
>
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-doc" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?87847.985204195>