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

[Alan Cox]

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

That doesn't matter.  To the rest of the VM system, and, in particular,
the page daemon, one category is indistinguishable from the other.