Try with this /etc/system tunings : 

set mac:mac_soft_ring_thread_bind=0
set mac:mac_srs_thread_bind=0
set zfs:zio_taskq_batch_pct=50

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 
> repurposed).
> 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...
>> Cheers,
>> --
>> Saso
>> _______________________________________________
>> zfs-discuss mailing list

zfs-discuss mailing list

Reply via email to