Try with this /etc/system tunings :
Le 12 juin 2012 à 11:37, Roch Bourbonnais a écrit :
> So the xcall are necessary part of memory reclaiming, when one needs to tear
> down the TLB entry mapping the physical memory (which can from here on be
> So the xcall are just part of this. Should not cause trouble, but they do.
> They consume a cpu for some time.
> That in turn can cause infrequent latency bubble on the network. A certain
> root cause of these latency bubble is that network thread are bound by
> default and
> if the xcall storm ends up on the CPU that the network thread is bound to, it
> will wait for the storm to pass.
> So try unbinding the mac threads; it may help you here.
> Le 12 juin 2012 à 09:57, Sašo Kiselkov a écrit :
>> Seems the problem is somewhat more egregious than I thought. The xcall
>> storm causes my network drivers to stop receiving IP multicast packets
>> and subsequently my recording applications record bad data, so
>> ultimately, this kind of isn't workable... I need to somehow resolve
>> this... I'm running four on-board Broadcom NICs in an LACP
>> aggregation. Any ideas on why this might be a side-effect? I'm really
>> kind of out of ideas here...
>> zfs-discuss mailing list
zfs-discuss mailing list