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/
Home Products Support Community News


Re: [Xen-devel] Automation scripts

To: Peri Hankey <mpah@xxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] Automation scripts
From: Ian Pratt <Ian.Pratt@xxxxxxxxxxxx>
Date: Tue, 28 Sep 2004 16:43:25 +0100
Cc: Ian Pratt <Ian.Pratt@xxxxxxxxxxxx>, Michael Vrable <mvrable@xxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxxx, Ian.Pratt@xxxxxxxxxxxx
Delivery-date: Tue, 28 Sep 2004 16:57:12 +0100
Envelope-to: steven.hand@xxxxxxxxxxxx
In-reply-to: Your message of "Tue, 28 Sep 2004 15:55:07 BST." <41597B4B.6020009@xxxxxxxxxxxxxx>
List-archive: <http://sourceforge.net/mailarchive/forum.php?forum=xen-devel>
List-help: <mailto:xen-devel-request@lists.sourceforge.net?subject=help>
List-id: List for Xen developers <xen-devel.lists.sourceforge.net>
List-post: <mailto:xen-devel@lists.sourceforge.net>
List-subscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=subscribe>
List-unsubscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=unsubscribe>
Sender: xen-devel-admin@xxxxxxxxxxxxxxxxxxxxx
> It looks as if lvm2 uses quite a lot of memory analysing multiple 
> snapshots of a single origin. I rebooted the dom0 machine and 
> immediately did 'vchange -ay vmspace' which makes the volume group 
> vmspace active. This claims to run out of memory - always so far on one 
> of a list of snapshots of a common origin, but not always on the same 
> one. When it runs out memory adding a new snapshot, it tends to mention 
> one of the other snapshots, and as I have said, the whole caboodle then 
> becomes unusable until after a reboot.

> dm-snapshot-in       128    162     48 
> dm-snapshot-ex     19556  19662     16 
> dm_tio             14336  14464     16 
> dm_io              14336  14464     16 

20,000 dm-snapshot-ex entries sounds like a lot, but they're only
16 bytes each. From looking at the code it looks like it needs to
store the entire exception table in memory rather than using it
as a cache of what's on disk, which is a shame. Still, 50k
x16 bytes is less than 1MB.

There's nothing in slabinfo that looks crazy. I wander where all
your memory is gone? BTW: how big is your dom0? 

It's possible that dm-io or kcopyd is chewing up pages (which
won't show up in the slab allocator). I'm surprised they're not
just transient, though.

Perhaps someone's going to need to take a look at device
mapper. Building a version with debug printk's enabled would be a
good start. I'd like to know what allocation is failing.


This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
Xen-devel mailing list