Ian Campbell wrote:
> On Thu, 2010-06-17 at 09:16 +0100, Xu, Dongxiao wrote:
>> Ian,
>>
>> Sorry for the late response, I was on vacation days before.
>
> I was also on vacation so sorry in _my_ late reply ;-)
>
>> Ian Campbell wrote:
>>> On Thu, 2010-06-10 at 12:48 +0100, Xu, Dongxiao wrote:
>>>> Hi Jeremy,
>>>>
>>>> The attached patch should fix the PV network issue after applying
>>>> the netback multiple threads patchset.
>>>
>>> Thanks for this Donxiao. Do you think this crash was a potential
>>> symptom of this issue? It does seem to go away if I apply your
>>> patch.
>>
>> Actually, the phenomenon is the same on my side without the fixing
>> patch.
>
> Great, thanks.
>
>>> On an unrelated note, do you have any plans to make the number of
>>> groups react dynamically to CPU hotplug? Not necessarily while
>>> there are actually active VIFs (might be tricky to get right) but
>>> perhaps only when netback is idle (i.e. when there are no VIFs
>>> configured), since often the dynamic adjustment of VCPUs happens at
>>> start of day to reduce the domain 0 VCPU allocation from the total
>>> number of cores in the machine to something more manageable.
>>
>> I'm sorry, currently I am busy with some other tasks and may not have
>> time to do this job.
>
> I understand.
>
>> But if the case is to reduce dom0 VCPU number, keep the group number
>> unchanged will not impact the performance, since the group reflects
>> the tasklet/kthread number, and it doesn't have direct association
>> with dom0's VCPU number.
>
> Yes, that mitigates the issue to a large degree. I was just concerned
> about e.g. 64 threads competing for 4VCPU or similar which seems
> wasteful in terms of some resource or other...
>
> For XCP (which may soon switch from 1 to 4 domain 0 VCPUS in the
> unstable branch) I've been thinking of the following patch. I wonder
> if
> it might make sense in general? 4 is rather arbitrarily chosen but I
> think even on a 64 core machine you wouldn't want to dedicate more
> than
> some fraction netback activity and if you do then it is configurable.
Basically I am OK with it.
One concern is that, when system is equipped with 10G NIC,
according to my previous experience, 4 dom0 vCPU may be not enough
for eating all the bandwidth.
Thanks,
Dongxiao
>
> Ian.
>
>
> netback: allow configuration of maximum number of groups to use
> limit to 4 by default.
>
> Signed-off-by: Ian Campbell <ian.campbell@xxxxxxxxxx>
>
> diff -r 7692c6381e1a drivers/xen/netback/netback.c
> --- a/drivers/xen/netback/netback.c Fri Jun 11 08:44:25 2010 +0100
> +++ b/drivers/xen/netback/netback.c Fri Jun 11 09:31:48 2010 +0100
> @@ -124,6 +124,10 @@
> static int MODPARM_netback_kthread = 1;
> module_param_named(netback_kthread, MODPARM_netback_kthread, bool,
> 0); MODULE_PARM_DESC(netback_kthread, "Use kernel thread to replace
> tasklet"); +
> +static unsigned int MODPARM_netback_max_groups = 4;
> +module_param_named(netback_max_groups, MODPARM_netback_max_groups,
> bool, 0); +MODULE_PARM_DESC(netback_max_groups, "Maximum number of
> netback groups to allocate");
>
> /*
> * Netback bottom half handler.
> @@ -1748,7 +1752,7 @@
> if (!is_running_on_xen())
> return -ENODEV;
>
> - xen_netbk_group_nr = num_online_cpus();
> + xen_netbk_group_nr = min(num_online_cpus(),
> MODPARM_netback_max_groups); xen_netbk = (struct xen_netbk
> *)vmalloc(sizeof(struct xen_netbk)
> * xen_netbk_group_nr);
> if (!xen_netbk) {
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home