svn commit: r267858 - in head/sys/dev: virtio/balloon xen/balloon

[Julian Elischer]

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 
>> <glebius at 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.