Date: Fri, 14 Feb 2014 14:57:19 -0800 From: Adrian Chadd <adrian@freebsd.org> To: John Baldwin <jhb@freebsd.org> Cc: "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org>, Ryan Stone <rysto32@gmail.com>, "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org> Subject: Re: can the scheduler decide to schedule an interrupted but runnable thread on another CPU core? What are the implications for code? Message-ID: <CAJ-Vmon6Rs05Ok23YRqGrML5UVa2%2BkeHC85=ms42esJc0S8vvQ@mail.gmail.com> In-Reply-To: <CAJ-Vmo=C4MRdyAGegD8MkCgx9ibbWtrWefYYugz=qpyOEmZcxg@mail.gmail.com> References: <CAJ-Vmo=7Nz1jqXy%2BrTQ7u9_ZP7jeFOKUJxU1O51tYJjvTUmWTg@mail.gmail.com> <201402141139.49158.jhb@freebsd.org> <CAJ-Vmo=vQ%2BMX%2Br3z6_Y4aJiWUBxXgXE7APjTsUysVPN2aoghXQ@mail.gmail.com> <201402141318.44743.jhb@freebsd.org> <CAJ-Vmo=C4MRdyAGegD8MkCgx9ibbWtrWefYYugz=qpyOEmZcxg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[snip] So it turns out that the threads somehow migrating between CPUs during flowtable_lookup_common() is the clock swi(s), which I'm guessing are driving the per-CPU TCP callwheel timeouts. It turns out the per-CPU clock swis aren't CPU-pinned, so they can be preempted and migrated. I'm not sure if this is correct behaviour. I'll experiment with pinning these to their base CPU and see if this causes issues. Thanks, -a
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-Vmon6Rs05Ok23YRqGrML5UVa2%2BkeHC85=ms42esJc0S8vvQ>