[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] Xen 4.0.1 "xc_map_foreign_batch: mmap failed: Cannot allocate memory"
- To: Jan Beulich <JBeulich@xxxxxxxxxx>
- From: Keir Fraser <keir@xxxxxxx>
- Date: Fri, 17 Dec 2010 10:06:05 +0000
- Cc: anthony.perard@xxxxxxxxxx, Charles Arnold <CARNOLD@xxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>, Stefano Stabellini <Stefano.Stabellini@xxxxxxxxxxxxx>
- Delivery-date: Fri, 17 Dec 2010 02:06:52 -0800
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:user-agent:date :subject:from:to:cc:message-id:thread-topic:thread-index:in-reply-to :mime-version:content-type:content-transfer-encoding; bh=/bEAbfw4FYEe8k0zbEHe6rrS8hboJtsOcep+Np6zgJ0=; b=ZTVPNPx1CsimWLtpAw7wBtn4gDv9y7vJi8O9hWb+L1En1KvKGHODOhcxaKkPjlsDBo 4XtuMSZ4TAgFxTzQENUPK6WcWczzpto4myvT+9hKwJuwLnmHJ0IcUFXwIolqupQwDiya pNN/R3brhuebJ7dccADzym5u16msFr40eiX28=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; b=P9VquaIvDqudDioLKBZQleSPjqTst3T/lZ6yFKkdLRJ+xZutKYQEZ0gCkiIpFEofCa AuC8imtmKV7OV374ivLwzInua60oM8mlt/0+41qgPtF5fAMj4NuO6ayJkwVdp1po9obH v9+AFGZ5lUUveDAm9/VlgsMx1UkX4SKDg5Ow8=
- List-id: Xen developer discussion <xen-devel.lists.xensource.com>
- Thread-index: Acud0gQ9I1xEWIAVOkKd5EWD6Dp87A==
- Thread-topic: [Xen-devel] Xen 4.0.1 "xc_map_foreign_batch: mmap failed: Cannot allocate memory"
On 17/12/2010 09:22, "Jan Beulich" <JBeulich@xxxxxxxxxx> wrote:
>> If we can work out and detect this limit, perhaps 64-bit qemu-dm could have
>> a mapping cache similar to 32-bit qemu-dm, limited to some fraction of the
>> detected mapping limit. And/or, on mapping failure, we could reclaim
>> resources by simply zapping the existing cached mappings. Seems there's a
>> few options. I don't really maintain qemu-dm myself -- you might get some
>> help from Ian Jackson, Stefano, or Anthony Perard if you need more advice.
> Looking forward to their comments.
One issue with a failure path added to just the 'mapping cache' is that, if
we have hit some hard mapping or VM limit for this process, various other
syscalls in other qemu subsystems may also start to fail. If we let
ourselves get to this point, it seems to be that handling it robustly might
be difficult. OTOH, it shouldn't be hard to do a lot better than we are
Xen-devel mailing list