Date: Wed, 1 Oct 2008 16:44:00 -0700 From: "Murty, Ravi" <ravi.murty@intel.com> To: <freebsd-hackers@freebsd.org> Cc: "Teller, Justin S" <justin.s.teller@intel.com> Subject: Sched_ule.c - 8.0 Message-ID: <AEBCFC23C0E40949B10BA2C224FC61B0087FA4DE@orsmsx416.amr.corp.intel.com>
next in thread | raw e-mail | index | archive | help
Hello All,
=20
I was browsing the ULE 8.0 scheduler code and happen to find something
interesting. This might be intentional; since I don't think it is that
big a deal and is certainly not a bug.
In the implementation of sched_affinity - which from what I understand
gets called when the cpuset mask for a thread or a process is setup and
threads need to potentially migrated.
The code is pretty straightforward and one of the checks it does is=20
=20
if (!TD_IS_RUNNING(td))
return;
=20
I initially read this to mean, if the thread isn't running, it's
probably inhibited and that's okay because when it wanders into
sched_add eventually and since its cpuset mask is setup, it'll make its
way to the runq of one of the "legal" cpus. However the very next
thought I had was this thread could be on a runq right now and the macro
will return the fact that the thread isn't running. In such a case we
would probably end up running on the wrong CPU for a while before
realizing that we aren't allowed to do so.
=20
Thanks
Ravi
=20
=20
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AEBCFC23C0E40949B10BA2C224FC61B0087FA4DE>