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>