axe vm.max_wired

Konstantin Belousov kostikbel at gmail.com
Sat Feb 2 16:25:18 UTC 2013


On Fri, Feb 01, 2013 at 10:23:46AM +0200, Andriy Gapon wrote:
> on 31/01/2013 11:18 Konstantin Belousov said the following:
> > On Wed, Jan 30, 2013 at 10:58:31PM +0200, Andriy Gapon wrote:
> >> on 02/06/2012 14:30 Andriy Gapon said the following:
> >>> o  There is also vm.max_wired sysctl (with no equivalent tunable), which
> >>> specifies number of _pages_ that can be wired system wide (by both kernel and
> >>> userland).  But note that the limit applies only to userland requests, the
> >>> kernel is allowed to wire new pages even when the limit is exceeded.  By default
> >>> the limit is set to 1/3 of available pages.
> >>
> >> I would like to propose to axe vm.max_wired limit.
> >> It is not good when too many pages are wired, but...
> >>
> >> This limit is quite arbitrary (why 1/3).
> >> It's no good for ZFS systems where e.g. 90% of memory can be normally wired by
> >> ZFS in kernel.
> >>
> >> So this limit should be either axed or perhaps replaced with some much higher
> >> limit like e.g. v_page_count - 2 * v_free_target or some such number "close" to
> >> v_page_count.
> >>
> > 
> > I dislike your proposal.
> > 
> > The limit is useful to prevent the system from entering live-lock.
> 
> Well, I definitely agree that we should prevent all of memory from becoming
> wired.  And I myself don't like full axing of vm.max_wired :-)
> 
> But I do not fully agree with your logic here.  Completely prohibiting any page
> wiring in userland would achieve the goal too, but that doesn't mean that that
> would be useful.

> 
> > ZFS-using machines should be tuned.
> 
> I would like them to be auto-tuned.
> 
> > Or finally the ZFS caches should
> > communicate the fact that the pages used are for caches and provide
> > easy way for the VM to request flush. This would be big project indeed.
> > 
> > E.g., could ZFS make an impression that zfs-cached pages are cached, to VM ?
> 
> I would love to have ZFS ARC implemented differently.
ZFS integration with the VM, is, to say it mildly, not good.

The fact that ZFS cache (ARC ?) presents the cached pages as wired,
makes the VM almost useless for a ZFS machine. Your displeasure and
tweaks should be directed to ZFS integration, and not to unbalancing
current tuning which is not that bad for ZFS-less boxes.

> But I do not expect that to happen soon.
> Regarding your question - I do not have an answer.  Perhaps let's discuss how
> that could be done (while preserving useful/advanced features of ARC)...
> 
> So, meanwhile, I object to your objection :-)
> You didn't explain why vm.max_wired should be 1/3 of v_page_count by default.
> You didn't explain how a situation where, say, 80% of pages are wired by kernel
> is radically better than a situation where 80% of pages are wired by kernel and
> 1% are wired by userland.
> 
> So, I still think that vm.max_wired as it is used now is too arbitrary and too
> indiscriminate to be useful.
It is sized well to the default size of the buffer map, which takes 10%
of the physical RAM of the machine. Since buffers wiring the pages, be
it VMIO or malloc buffer, this leaves 20% for other things, like mbufs,
page tables and user wires.

> 
> There are other tools to limit page wiring by userland e.g. memlocked limit.
The memlock limit is per-process. It is completely useless as the safety
measure.

> 
> But, as I've said in the original email, I can agree with vm.max_wired
> usefulness if it is set to something more reasonable by default.
> IMO, it should not be a fixed percentage of available memory, it should be
> derived from other VM thresholds related to paging.

Might be. Please provide a suggestion or better, a change.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 834 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20130202/d3d972d8/attachment.sig>


More information about the freebsd-arch mailing list