Date: Fri, 13 Apr 2018 13:31:11 -0400 From: Stephen Hurd <shurd@llnw.com> To: Ryan Stone <rysto32@gmail.com> Cc: Stephen Hurd <shurd@freebsd.org>, src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-stable@freebsd.org, svn-src-stable-11@freebsd.org Subject: Re: svn commit: r332447 - stable/11/sys/dev/ixgbe Message-ID: <CAGK_Ob1nJHuMwdJBp9vCSsm3o0pCuDo6gg5eUyS7CrFWa-NAZw@mail.gmail.com> In-Reply-To: <CAFMmRNwM6Y6fs2dR97zX6qnoGqDJnwf3Vha8wi-RReBcbKwRcQ@mail.gmail.com> References: <201804121906.w3CJ6FZo092138@repo.freebsd.org> <CAFMmRNwM6Y6fs2dR97zX6qnoGqDJnwf3Vha8wi-RReBcbKwRcQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Yeah, I'm looking at the changes that caused this now. Hopefully I'll have this updated today. On Thu, Apr 12, 2018 at 4:01 PM, Ryan Stone <rysto32@gmail.com> wrote: > Spinning in the kernel for a full second is a really bad idea. At > minimum this is going to hold off all callouts from one of the callout > threads for up to a full second as ixgbe_local_timer() waits for the > core mutex. That chews up two CPU cores doing busy-wait loops (the > ixgbe_stop() thread busy-waits in msec_delay and the callout thread > adaptively spins waiting for the mutex). If any other thread tries to > acquire the core lock they also adaptively spin on the mutex chewing > up yet more cores. This includes any threads trying to fetch > interface status (e.g. ifconfig), various interrupt handlers, etc. > -- [image: Limelight Networks] <http://www.limelight.com>; Stephen Hurd* Principal Engineer* EXPERIENCE FIRST. +1 616 848 0643 <+1+616+848+0643> www.limelight.com [image: Facebook] <https://www.facebook.com/LimelightNetworks>[image: LinkedIn] <http://www.linkedin.com/company/limelight-networks>[image: Twitter] <https://twitter.com/llnw>;
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAGK_Ob1nJHuMwdJBp9vCSsm3o0pCuDo6gg5eUyS7CrFWa-NAZw>