On Wed, Jun 25, 2014 at 5:16 PM, Alfred Perlstein <alf...@freebsd.org> 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.
Well, assuming you trace them indipendently I don't think this is going to be problematic to aggregate them, is it? As far as I understand it, right now we have RMEM_LIMIT to someway limit per-process amount of wired memory and finally max_wired as a global accounted wired memory limit. I think that the idea now is that RMEM_LIMIT is enough to correctly control all the front-end check, coming from untrusted sources (userland, non-privileged syscalls like mlock(), mmap(), etc.). Possibly that's not always the case and I think that the hypervisor can be a fair example of this. Having "more granular" accountability, means that rather than having a global limit (or, rather, along with it) we can grow a per-process limit to control kernel-allocated wired memory. > Perhaps that needs an API as well? I don't have anything in my mind yet. My initial point was more trying to get a better semantic on a paradigm that is at least dangerous. Attilio -- Peace can only be achieved by understanding - A. Einstein _______________________________________________ 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"
