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@opensolaris.org >> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss > _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
