diff options
| author | emax <emax@FreeBSD.org> | 2012-06-05 18:48:02 +0000 |
|---|---|---|
| committer | emax <emax@FreeBSD.org> | 2012-06-05 18:48:02 +0000 |
| commit | ce863bea70dadac926bfa95aae9556285aef43cb (patch) | |
| tree | 633b5ae3b9d4086a402f340c8b33f210b64c4a8a /lib/libgssapi/gss_inquire_sec_context_by_oid.c | |
| parent | 5b88f5a88f36f171fa8fa7a9eb509f4fb78672a6 (diff) | |
| download | FreeBSD-src-ce863bea70dadac926bfa95aae9556285aef43cb.zip FreeBSD-src-ce863bea70dadac926bfa95aae9556285aef43cb.tar.gz | |
Before it gets lost in the noise.
Put a bandaid to prevent ixgbe(4) from completely locking up the system
under high load. Our platform has a few CPU cores and a single active
ixgbe(4) port with 4 queues. Under high enough traffic load, at about
7.5GBs and 700,000 packets/sec (outbound), the entire system would
deadlock. What we found was that each CPU was in an endless loop on a
different ix taskqueue thread. The OACTIVE flag had gotten set on each
queue, and the ixgbe_handle_queue() function was continuously rescheduling
itself via the taskqueue_enqueue. Since all CPUs were busy with their
taskqueue threads, the ixgbe_local_timer() function couldn't run to clear
the OACTIVE flag.
Submitted by: scottl
MFC after: 1 week
Diffstat (limited to 'lib/libgssapi/gss_inquire_sec_context_by_oid.c')
0 files changed, 0 insertions, 0 deletions
