Date: Sat, 15 Feb 2014 02:08:38 +0400 From: Andrey Chernov <ache@freebsd.org> To: John Baldwin <jhb@freebsd.org> Cc: "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org>, Adrian Chadd <adrian@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: <52FE93E6.6030705@freebsd.org> In-Reply-To: <201402141410.29325.jhb@freebsd.org> References: <CAJ-Vmo=7Nz1jqXy%2BrTQ7u9_ZP7jeFOKUJxU1O51tYJjvTUmWTg@mail.gmail.com> <201402141318.44743.jhb@freebsd.org> <52FE5FBF.3090104@freebsd.org> <201402141410.29325.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 14.02.2014 23:10, John Baldwin wrote: >> Due to this bug, not fixed yet, the real picture is more complex: >> http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/163585 > > Eh, that bug report has no useful details, as in, it doesn't list the > actual commands run. If you do 'cpuset -l 6 -s 1' to force all > processes to only use CPU6, then yes, of course the other CPUs are idle > because that's what you _asked_ for. AFAICT, that is all the original > reporter did. At work we regularly add and remove CPUs from the > default set (set 1) on hundreds of machines every day with ULE without > any issues. Probably original report lack certain commands, but I provide the link to the port which reproduces this bug too. All threads there are assigned to the _different_ CPUs and appears as result on single one with SCHED_ULE (not with SCHED_4BSD). And it is what original reporter mean too. It surely happens, maybe not the first time, but on 2nd-3rd. It means that cpuset_setaffinity() is completely broken form SCHED_ULE at least for 3 years. -- http://ache.vniz.net/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?52FE93E6.6030705>