Re: [patch] sched_[set|get]_affinity() syscall, 2.4.15-pre9

Ingo Molnar (mingo@elte.hu)
Fri, 23 Nov 2001 12:36:27 +0100 (CET)


This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
Send mail to mime@docserver.cac.washington.edu for more info.

--8323328-421162814-1006515387=:3988
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Thu, 22 Nov 2001, Ryan Cumming wrote:

> [...] a /proc interface would allow me to change the CPU affinity of
> processes that aren't {get, set}_affinity aware (i.e., all Linux
> applications written up to this point). [...]

had you read my patch then you'd perhaps have noticed how easy it is
actually. I've attached a simple utility called 'chaff' (change affinity)
that allows to change the affinity of unaware processes:

mars:~> ./chaff 714 0xf0
pid 714's old affinity: 000000ff.
pid 714's new affinity: 000000f0.

> And one final thing... what sort of benifit does CPU affinity have if
> we have the scheduler take in account CPU migration costs correctly?
> [...]

while you are right that the scheduler can and should guess lots of
things, but it cannot guess some things. Eg. it has no idea whether a
particular process' workload is related to any IRQ source or not. And if
we bind IRQ sources for performance reasons, then the scheduler has no
chance finding the right CPU for the process. (I have attempted to
implement such a generic mechanizm a few months ago but quickly realized
that nothing like that will ever be accepted in the mainline kernel -
there is simply no way establish any reliable link between IRQ load and
process activities.)

So i implemented the smp_affinity and ->cpus_allowed mechanizms to allow
specific applications (who know the kind of load they generate) to bind to
specific CPUs, and to bind IRQs to CPUs. Obviously we still want the
scheduler to make good decisions - but linking IRQ load and scheduling
activity is too expensive. (i have a scheduler improvement patch that does
do some of this work at wakeup time, and which patch benefits Apache, but
this is still not enough to get the 'best' affinity.)

Ingo

--8323328-421162814-1006515387=:3988
Content-Type: TEXT/PLAIN; charset=US-ASCII; name="chaff.c"
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.LNX.4.33.0111231236270.3988@localhost.localdomain>
Content-Description:
Content-Disposition: attachment; filename="chaff.c"

DQovKg0KICogU2ltcGxlIGxvb3AgdGVzdGluZyB0aGUgQ1BVLWFmZmluaXR5
IHN5c2NhbGwuDQogKi8NCiNpbmNsdWRlIDx0aW1lLmg+DQojaW5jbHVkZSA8
c3RkaW8uaD4NCiNpbmNsdWRlIDxzdGRsaWIuaD4NCiNpbmNsdWRlIDxsaW51
eC91bmlzdGQuaD4NCg0KI2RlZmluZSBfX05SX3NjaGVkX3NldF9hZmZpbml0
eSAyMjYNCl9zeXNjYWxsMyAoaW50LCBzY2hlZF9zZXRfYWZmaW5pdHksIHBp
ZF90LCBwaWQsIHVuc2lnbmVkIGludCwgbWFza19sZW4sIHVuc2lnbmVkIGxv
bmcgKiwgbWFzaykNCg0KI2RlZmluZSBfX05SX3NjaGVkX2dldF9hZmZpbml0
eSAyMjcNCl9zeXNjYWxsMyAoaW50LCBzY2hlZF9nZXRfYWZmaW5pdHksIHBp
ZF90LCBwaWQsIHVuc2lnbmVkIGludCAqLCBtYXNrX2xlbiwgdW5zaWduZWQg
bG9uZyAqLCBtYXNrKQ0KDQppbnQgbWFpbiAoaW50IGFyZ2MsIGNoYXIgKiph
cmd2KQ0Kew0KCWludCBwaWQsIHJldDsNCgl1bnNpZ25lZCBpbnQgbWFza19s
ZW47DQoJdW5zaWduZWQgbG9uZyBtYXNrLCBuZXdfbWFzazsNCg0KCWlmIChh
cmdjICE9IDMpIHsNCgkJcHJpbnRmKCJ1c2FnZTogY2hhZmYgPHBpZD4gPGhl
eF9tYXNrPlxuIik7DQoJCWV4aXQoLTEpOw0KCX0NCglwaWQgPSBhdG9sKGFy
Z3ZbMV0pOw0KCXNzY2FuZihhcmd2WzJdLCAiJWx4IiwgJm5ld19tYXNrKTsN
Cg0KcHJpbnRmKCJwaWQ6ICVkLiBuZXdfbWFzazogKCVzKSAlMDhseC5cbiIs
IHBpZCwgYXJndlsyXSwgbmV3X21hc2spOw0KDQoJcmV0ID0gc2NoZWRfZ2V0
X2FmZmluaXR5KHBpZCwgJm1hc2tfbGVuLCAmbWFzayk7DQoJaWYgKHJldCkg
ew0KCQlwcmludGYoImNvdWxkIG5vdCBnZXQgcGlkICVkJ3MgYWZmaW5pdHku
XG4iLCBwaWQpOw0KCQlyZXR1cm4gLTE7DQoJfQ0KCXByaW50ZigicGlkICVk
J3Mgb2xkIGFmZmluaXR5OiAlMDhseC4iLCBwaWQsIG1hc2spOw0KDQoJcmV0
ID0gc2NoZWRfc2V0X2FmZmluaXR5KHBpZCwgc2l6ZW9mKG5ld19tYXNrKSwg
Jm5ld19tYXNrKTsNCglpZiAocmV0KSB7DQoJCXByaW50ZigiY291bGQgbm90
IHNldCBwaWQgJWQncyBhZmZpbml0eS5cbiIsIHBpZCk7DQoJCXJldHVybiAt
MTsNCgl9DQoJcmV0ID0gc2NoZWRfZ2V0X2FmZmluaXR5KHBpZCwgJm1hc2tf
bGVuLCAmbWFzayk7DQoJaWYgKHJldCkgew0KCQlwcmludGYoInNjaGVkX2dl
dF9hZmZpbml0eSByZXR1cm5lZCAlZCwgZXhpdGluZy5cbiIsIHJldCk7DQoJ
CXJldHVybiAtMTsNCgl9DQoJcHJpbnRmKCJwaWQgJWQncyBuZXcgYWZmaW5p
dHk6ICUwOGx4LiIsIHBpZCwgbWFzayk7DQoJcmV0dXJuIDA7DQp9DQo=
--8323328-421162814-1006515387=:3988--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/