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][Pv-ops][PATCH 0/3 v3] Netback multiple threads support

To: "Dongxiao Xu" <dongxiao.xu@xxxxxxxxx>
Subject: Re: [Xen-devel][Pv-ops][PATCH 0/3 v3] Netback multiple threads support
From: "Jan Beulich" <JBeulich@xxxxxxxxxx>
Date: Tue, 04 May 2010 10:38:35 +0100
Cc: Jeremy Fitzhardinge <jeremy@xxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Steven Smith <steven.smith@xxxxxxxxxx>, KonradRzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
Delivery-date: Tue, 04 May 2010 02:38:15 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <D5AB6E638E5A3E4B8F4406B113A5A19A1D94B446@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
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: <D5AB6E638E5A3E4B8F4406B113A5A19A1D94B446@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>>> "Xu, Dongxiao" <dongxiao.xu@xxxxxxxxx> 04.05.10 03:52 >>>
>1. Merge "group" and "idx" into "netif->mapping", therefore
>page_ext is not used now.

Open coding this seems very fragile (and even more using literal
constants in those code fragments).

I'm also not convinced restricting either part to 16 bits is a good thing
(particularly on 64-bits, where you could easily have each part use
32 bits).

>2. Put netbk_add_netif() and netbk_remove_netif() into
>__netif_up() and __netif_down().

An extra comment on top of what I said earlier: I don't think holding
the lock for the entire duration of the loop in netbk_add_netif() is
necessary - not doing so just makes the balancing slightly imprecise,
but reduces (on large systems) the spin lock holding time (perhaps

If you don't, and if you instead make the netfront_count member
an atomic_t, you can eliminate the lock altogether I would think.

>4. Use __get_free_pages() to replace kzalloc().

This is only marginally better than kzalloc(). Why not vmalloc(), as

>6. Use MODPARM_netback_kthread to determine whether using
>tasklet or kernel thread.

As a minor space optimization, the tasklet and kthread related
fields in struct xen_netbk could be put in a union.

>8. Add more checks in netif_page_release().

Actually, isn't


checking just a subset of

        BUG_ON(netbk->mmap_pages[idx] != page);

as all pages in those arrays would always be foreign?


Xen-devel mailing list