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] Assigning contiguous memory to a driver domain

To: Goswin von Brederlow <goswin-v-b@xxxxxx>
Subject: Re: [Xen-devel] Assigning contiguous memory to a driver domain
From: Rafal Wojtczuk <rafal@xxxxxxxxxxxxxxxxxxxxxx>
Date: Wed, 15 Sep 2010 14:06:26 +0200
Cc: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, Joanna Rutkowska <joanna@xxxxxxxxxxxxxxxxxxxxxx>, Jan Beulich <JBeulich@xxxxxxxxxx>, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
Delivery-date: Wed, 15 Sep 2010 05:10:57 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <87pqwfgqvt.fsf@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: <20100914092439.GA1000@email> <4C8F5E580200007800015F71@xxxxxxxxxxxxxxxxxx> <20100915090842.GB1583@email> <20100915093910.GC1583@email> <4C90B31902000078000163E8@xxxxxxxxxxxxxxxxxx> <4C90A32A.7010803@xxxxxxxxxxxxxxxxxxxxxx> <4C90C3200200007800016442@xxxxxxxxxxxxxxxxxx> <4C90A8E4.9090004@xxxxxxxxxxxxxxxxxxxxxx> <4C90CF39020000780001647E@xxxxxxxxxxxxxxxxxx> <87pqwfgqvt.fsf@xxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.20 (2009-12-10)
On Wed, Sep 15, 2010 at 01:58:30PM +0200, Goswin von Brederlow wrote:
> "Jan Beulich" <JBeulich@xxxxxxxxxx> writes:
> >> Well, we do have 2 driver domains in Qubes: one is the netvm (NIC
> >> drivers), and the other one is Dom0 (storage, video, etc). BTW, how is
> >> it that the drivers in Dom0 never has this problem with allocating
> >> continues memory (even if we keep xen free memory = 0)?
> >
> > Merely because post-boot there would not usually be allocations.
> It is also called fragmentation.
> dom0 gets its memory at the start and probably all in one big
> chunk. Other domains have to use the bits and pices that happen to be
> free when the domain is started.

It does not look right. Jan has already written
* No, how (dis)contiguous the memory of a domain is doesn't matter
* here. What matters is whether the domain can *make* the requested
* memory contiguous, and that depends on how much contiguous
* memory Xen has at the point of the allocation.

> > Merely because post-boot there would not usually be allocations.
It is not too convincing, either. Firstly, assuming there is no dom0mem
parameter to Xen, dom0 gets all memory initially, so when dom0 boots the
first time, Xen free memory = 0 ? And drivers load fine.
Secondly, by default on Fedora, the pm-utils scripts tell NetworkManager to
turn off networking just before entering S3 sleep, and NetworkManager downs all
interfaces. It brings them up on resume. And apparently there are some
drivers, like tg3, that needs to alloc when bringing up the device. Still,
suspend/resume works when all devices are assigned to dom0.

Is it possible that swiotlb layer works differently in dom0 case ? Swiotlb
is switched on by default in dom0 case, is it correct ?

Rafal Wojtczuk

Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>