WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [PATCH] xen-mapcache: Fix rlimit set size.

To: Jan Beulich <jbeulich@xxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] xen-mapcache: Fix rlimit set size.
From: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
Date: Tue, 2 Aug 2011 23:03:37 +0100
Cc: Anthony Perard <anthony.perard@xxxxxxxxxx>, "agraf@xxxxxxx" <agraf@xxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, "qemu-devel@xxxxxxxxxx" <qemu-devel@xxxxxxxxxx>, Stefano Stabellini <Stefano.Stabellini@xxxxxxxxxxxxx>
Delivery-date: Tue, 02 Aug 2011 14:59:24 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4E3758920200007800073E55@xxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <4E3758920200007800073E55@xxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Alpine 2.00 (DEB 1167 2008-08-23)
On Tue, 2 Aug 2011, Jan Beulich wrote:
> >>> Anthony PERARD 08/01/11 9:27 PM >>> 
> >Previously, the address space soft limit was set mcache_max_size. So, 
> >before the mcache_max_size was reached by the mapcache, QEMU was killed 
> >for overuse of the virtual address space.
> >
> >This patch fix that by setting the soft limit to mcache_max_size + 80MB. 
> >I observed that QEMU use 75MB more than max_mcache_size after several 
> >empirical tests. 
> 
> Rather fragile going forward I would say. 

Yes, I agree. At the very least we should print a warning if rlimit_max
is too low so that the admin can fix it.

> I there any reason not to set
> the limit to infinity?
 
We shouldn't assume that qemu is running as a privileged process, but
if it is we should definitely do it.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel