On 06/25/2014 12:12, Julian Elischer wrote: > On 6/25/14, 11:16 PM, Alfred Perlstein wrote: >> On 6/25/14 5:41 AM, Attilio Rao wrote: >>> On Wed, Jun 25, 2014 at 2:09 PM, Gleb Smirnoff <gleb...@freebsd.org> >>> wrote: >>>> On Wed, Jun 25, 2014 at 01:58:29PM +0200, Attilio Rao wrote: >>>> A> > Log: >>>> A> > xen/virtio: fix balloon drivers to not mark pages as WIRED >>>> A> > >>>> A> > Prevent the Xen and VirtIO balloon drivers from marking >>>> pages as >>>> A> > wired. This prevents them from increasing the system wired >>>> page count, >>>> A> > which can lead to mlock failing because of hitting the limit in >>>> A> > vm.max_wired. >>>> A> >>>> A> This change is conceptually wrong. >>>> A> The pages balloon is allocating are unmanaged and they should be >>>> wired >>>> A> by definition. Alan and I are considering enforcing this (mandatory >>>> A> wired pages for unmanaged pages allocation) directly in the KPI. >>>> A> This in practice just seem an artifact to deal with scarce wired >>>> A> memory limit. I suggest that for the XEN case this limit gets >>>> bumped >>>> A> rather relying on similar type of hacks. >>>> >>>> Proper limit would be to count pages wired by userland via mlock(2) >>>> and enforce limit only on those pages. Pages wired by kernel should >>>> be either unlimited or controled by a separate limit. >>> FWIW, I mostly agree with this. I think that the kernel and userland >>> limits should be split apart. But for the time being, rising the limit >>> is better. >>> >>> Attilio >>> >>> >> Can you explain? I would think that if you were designing some kind >> of embedded device you would want to know exactly how much locked >> pages there are overall, not just in userland. >> >> Meaning you would not want to overcommit and have too many locked >> pages due to kernel+user. >> >> Perhaps that needs an API as well? > > these pages are the VM equivalent of memory pages that were 'found to > be flaky and taken out of service" > I think "wired" is a bad description for those. > > >
That doesn't matter. To the rest of the VM system, and, in particular, the page daemon, one category is indistinguishable from the other. _______________________________________________ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
