xen-devel
[Xen-devel] RE: Tmem vs order>0 allocation, workaround RFC
To: |
Jan Beulich <JBeulich@xxxxxxxxxx> |
Subject: |
[Xen-devel] RE: Tmem vs order>0 allocation, workaround RFC |
From: |
Dan Magenheimer <dan.magenheimer@xxxxxxxxxx> |
Date: |
Tue, 16 Feb 2010 08:44:11 -0800 (PST) |
Cc: |
xen-devel@xxxxxxxxxxxxxxxxxxx, AndrewPeace <Andrew.Peace@xxxxxxxxxxxxx>, George Dunlap <George.Dunlap@xxxxxxxxxxxxx>, kurt.hackel@xxxxxxxxxx, Ian Pratt <Ian.Pratt@xxxxxxxxxxxxx>, TimDeegan <Tim.Deegan@xxxxxxxxxxxxx>, Patrick Colp <pjcolp@xxxxxxxxx>, KeirFraser <keir.fraser@xxxxxxxxxxxxx>, Grzegorz Milos <gm281@xxxxxxxxx> |
Delivery-date: |
Tue, 16 Feb 2010 08:47:08 -0800 |
Envelope-to: |
www-data@xxxxxxxxxxxxxxxxxxx |
In-reply-to: |
<4B7ACBBF020000780002FA64@xxxxxxxxxxxxxxxxxx> |
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: |
<2af13319-6b44-44e2-ab62-a0615208cf64@default> <C79F1B58.A196%keir.fraser@xxxxxxxxxxxxx> <78c49794-4454-4c3b-80a6-72efcbc73fb3@default><78c49794-4454-4c3b-80a6-72efcbc73fb3@default> <057c0f45-9c97-4b8a-8efa-1726fd951e19@default> <4B7A6363020000780002F93C@xxxxxxxxxxxxxxxxxx><4B7A6363020000780002F93C@xxxxxxxxxxxxxxxxxx> <d2556e50-476d-487d-8fa8-aae67f63396c@default> <4B7AC4AD020000780002FA3D@xxxxxxxxxxxxxxxxxx><4B7AC4AD020000780002FA3D@xxxxxxxxxxxxxxxxxx> <816f818b-b45a-4e74-8b01-0409fd50f578@default 4B7ACBBF020000780002FA64@xxxxxxxxxxxxxxxxxx> |
Sender: |
xen-devel-bounces@xxxxxxxxxxxxxxxxxxx |
Hi Jan --
Fair enough. You've convinced me that I shouldn't push for
tmem to be turned back on by default for the official
Xen 4.0 release. But the patch as just checked-in by Keir
limits allocations only if tmem is enabled so I will just
document that tmem may cause problems if 32-bit-limited
devices are in the system. (I'd expect that to be rare in
the cloud environment where tmem would be most used.)
I do think it's unfortunate (turning off tmem by default)
as I suspect that "thar be (more) dragons" in Xen, when
trying to do any kind of memory utilization optimization,
that will come back and bite us. Tmem is just the first
to aggressively pursue this and disabling it only delays
the inevitable. For example, I'll bet improvements to
NUMA support will have many similar problems.
Anyway, thanks as usual for thinking deeply through the
issue and for trying out tmem... any new technology is
going to have some growing pains.
Thanks again,
Dan
> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@xxxxxxxxxx]
> Sent: Tuesday, February 16, 2010 8:46 AM
> To: Dan Magenheimer
> Cc: Grzegorz Milos; Patrick Colp; AndrewPeace; George Dunlap; Ian
> Pratt; KeirFraser; TimDeegan; xen-devel@xxxxxxxxxxxxxxxxxxx; Kurt
> Hackel
> Subject: RE: Tmem vs order>0 allocation, workaround RFC
>
> >>> Dan Magenheimer <dan.magenheimer@xxxxxxxxxx> 16.02.10 16:31 >>>
> >> From: Jan Beulich [mailto:JBeulich@xxxxxxxxxx]
> >> Subject: RE: Tmem vs order>0 allocation, workaround RFC
> >>
> >> >>> Dan Magenheimer <dan.magenheimer@xxxxxxxxxx> 16.02.10 16:05 >>>
> >> >Under what circumstances does dom0 require single-page-below-4G
> >> >allocations? Is it only for bounce buffers for PCI passthrough
> >> >of old devices with 32-bit addressing limitations? Or am I
> >>> >missing a much more common case?
> >>
> >> Not just for pass-through; all devices only supporting 32-bit
> >> addressing would have such requirements, and particularly common
> >> ones are display adapters which have DRM/AGP drivers loaded for
> >> them.
> >
> >Right, but those are statically allocated when dom0 is
> >launched, not dynamically allocated later after tmem
> >(or other memory allocation technologies) begin working,
> >right? Whereas pass-through devices would need below-4G
> >pages later?
>
> No, consistent/coherent allocations can happen at run time.
> Typically the largest share of the allocations would happen when
> the respective driver loads, but especially for the DRM/AGP case
> I think allocations get triggered by user mode (X initializing a
> display), which may happen at any time.
>
> >(And 32-bit devices in a 1TB machine seems a bit of a
> >stretch, but I suppose it is good to enumerate all the
> >cases.)
>
> Yes, but the 1Tb was just taken as an extreme example. Issues may
> arise earlier. And the display adapter part would likely remain valid
> even there - just see the use of vmalloc_32() in
> drivers/gpu/drm/drm_scatter.c for an example.
>
> Jan
>
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- [Xen-devel] RE: Tmem vs order>0 allocation, workaround RFC, (continued)
- [Xen-devel] RE: Tmem vs order>0 allocation, workaround RFC, Dan Magenheimer
- [Xen-devel] Re: Tmem vs order>0 allocation, workaround RFC, Keir Fraser
- [Xen-devel] RE: Tmem vs order>0 allocation, workaround RFC, Dan Magenheimer
- [Xen-devel] Re: Tmem vs order>0 allocation, workaround RFC, Keir Fraser
- [Xen-devel] RE: Tmem vs order>0 allocation, workaround RFC, Dan Magenheimer
- [Xen-devel] RE: Tmem vs order>0 allocation, workaround RFC, Jan Beulich
- [Xen-devel] RE: Tmem vs order>0 allocation, workaround RFC, Dan Magenheimer
- [Xen-devel] RE: Tmem vs order>0 allocation, workaround RFC, Jan Beulich
- [Xen-devel] RE: Tmem vs order>0 allocation, workaround RFC, Dan Magenheimer
- [Xen-devel] RE: Tmem vs order>0 allocation, workaround RFC, Jan Beulich
- [Xen-devel] RE: Tmem vs order>0 allocation, workaround RFC,
Dan Magenheimer <=
- Re: [Xen-devel] RE: Tmem vs order>0 allocation, workaround RFC, Konrad Rzeszutek Wilk
|
|
|