Date: Mon, 13 Oct 2008 10:24:30 -0500 (CDT) From: Mark Tinguely <tinguely@casselton.net> To: fbsdlists@gmail.com, tinguely@casselton.net Cc: freebsd-questions@freebsd.org Subject: Re: kernel: Approaching the limit on PV entries... Message-ID: <200810131524.m9DFOU5i069178@casselton.net> In-Reply-To: <54db43990810130621s63ea1ec9nc085d79b0c230ad6@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> Thanks. I'll see what happens. > > In amd64/7.0 is there any chance running out of pv_entrys would show > up as failures in interprocess communication rather than a panic? The > original symptom was that certain web pages (or jailed servers, I'm > not sure) were unreachable, as if the firewall were misconfigured, > until the system was rebooted. I didn't get to look at the system > before it was rebooted, and I find very little in the logs to explain > what was going on. Sometimes pv_entry allocation can fail even below the pv_entry_high_water if there is no more free pages available to allocate for a pv_entry chunk. Operations (such temp mappings, copies) will not occur if the pv_entry_high_water (90% if pv_entry_max) has been reached OR a page is not immediately available for allocation. The first situation is quiet, you could put a sysctl counter. Maybe PV_STAT(pc_chunk_tryfail++) should be moved from get_pv_entry() to the "else" case of the routine pmap_try_insert_pv_entry(). On the other hand, some allocations (permanent mapping) are unconditional and can occur even when pv_entry_max has been exceeded (amd64). The code will also wait for page allocations. --Mark Tinguely.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200810131524.m9DFOU5i069178>