Date: Wed, 21 Mar 2001 16:14:32 -0300 (BRST) From: Rik van Riel <riel@conectiva.com.br> To: Matt Dillon <dillon@earth.backplane.com> Cc: Alfred Perlstein <bright@wintelcom.net>, 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: <Pine.LNX.4.21.0103211605310.9056-100000@imladris.rielhome.conectiva> In-Reply-To: <200103211840.f2LIeYA16476@earth.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 21 Mar 2001, Matt Dillon wrote:
> 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;
The (maybe too lightweight) structure I have in my patch
looks like this:
struct pte_chain {
struct pte_chain * next;
pte_t * ptep;
};
Each pte_chain hangs off a page of physical memory and the
ptep is a pointer to a page table entry.
The page struct of the page table page itself is used to
note down which address space and offset we have. This means
that FreeBSD's pv_pmap, pv_va and pv_ptem are in the page
table page and NOT in each pte_chain structure...
The only issue is address space rundowns, but this _could_
be ok due to the fact that systems usually seem to have more
short-running processes than long-running ones and the tasks
that are short-running will have their pte_chain nearer to
the beginning of the list.
Finding all pages in an address_space is simply done by walking
the populated parts of the page tables, this is cache friendly
and relatively fast for everything except really huge sparse
mappings (but in that case, the finer grained locking makes sure
this penalty gets restricted to the exiting task only and doesn't
block the rest of the system).
The whole patch is available at:
http://www.surriel.com/patches/2.4/2.4.1-pmap-swapsonuml
I have some newer code available, but haven't bothered coding
up a new patch yet since the reverse mapping is experimental
stuff and we're still busy finetuning and debugging 2.4 ;)
regards,
Rik
--
Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...
http://www.surriel.com/
http://www.conectiva.com/ http://distro.conectiva.com.br/
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?Pine.LNX.4.21.0103211605310.9056-100000>