Re: SCHED_IDLE patch

MOLNAR Ingo (mingo@chiara.csoma.elte.hu)
Tue, 20 Oct 1998 02:56:13 +0200 (CEST)


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.

---1247997369-209215680-908844973=:24868
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Mon, 19 Oct 1998, Rik van Riel wrote:

> As usual, the SCHED_IDLE patch has some problems:

(i assume you refer to the small SCHED_IDLE patch i posted some 1.5 years
ago, which introduces a new scheduling class and Harald Koenig's small
utility that makes use of it. I've attached both of them for reference)

> - if you run more SCHED_IDLE processes, only the first
> one will get any CPU time assigned

nope they will eat up their timeslice and the next one comes, just like RT
processes do. This makes sense from the cache-usage point of view,
SCHED_IDLE processes obviosly dont have any inteactivity needs, so the
longer the timeslice, the better the overall system performance. Think RC5
cracker.

> - it is a gross hack (well, the nice +20 part looks nice
> to me, but the other parts don't)

(here you obviosly talk about that other patch, the SCHED_IDLE patch is a
new scheduling class)

> - it will have continuous recalculation of all process
> priorities

nope they will have recalculation once all SCHED_IDLE processes reach
counter 0, this is normal behavior for Linux.

> with the nice +20 hack ;).

i'm not convinced about nice +20. It hardwires things that should not be
hardwired. SCHED_IDLE is different from a nice-level, as it's a new
scheduling class. (eg. it can easily be extended to be even less idle than
now, ie. only starting up after the system has been _really_ idle for some
given timeout, this gives preference for sleep-and-wakeup-soon processes
not getting their caches trashed) The point: SCHED_IDLE is _really_
different even if it looks alot like nice 19 on the surface. Scheduling
priorities are a fundamentally non-onedimensional problem.

Also, in RL i'm using nice(10000) and 'nice 10000' frequently, just
because sometimes i dont remember wether it's 0-40 or -20 to +20 :) If it
did a sys_nice(+20) it would give very bad interactive performance
compared to a nice +19 process.

-- mingo

---1247997369-209215680-908844973=:24868
Content-Type: TEXT/PLAIN; charset=US-ASCII; name="sched-idle-2.0.30"
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.LNX.3.96.981020025613.24868D@chiara.csoma.elte.hu>
Content-Description:

DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQovKiBzY2hl
ZF9pZGxlLmMsIChDKSAxOTk3IEguIEtvZW5pZywgcHV0IHVuZGVyIEdQTCAq
Lw0KDQojaW5jbHVkZSA8dW5pc3RkLmg+DQojaW5jbHVkZSA8c3RkaW8uaD4N
CiNpbmNsdWRlIDxlcnJuby5oPg0KI2luY2x1ZGUgPGxpbnV4L3NjaGVkLmg+
DQoNCm1haW4oaW50IGFyZ2MsIGNoYXIgKmFyZ3ZbXSkNCnsNCiAgc3RydWN0
IHNjaGVkX3BhcmFtIHNwOw0KICBpbnQgbmljZWxldmVsID0gMTk7DQoNCiAg
aWYgKGFyZ2MgPD0gMSkgew0KICAgIHByaW50ZigidXNhZ2U6ICVzICBwcm9n
cmFtIFsgYXJndW1lbnRzLi4uIF1cbiIsYXJndlswXSk7DQogICAgZXhpdCgx
KTsNCiAgfQ0KDQogIHNwLnNjaGVkX3ByaW9yaXR5ID0gMTsNCiAgc2NoZWRf
c2V0c2NoZWR1bGVyKDAsIFNDSEVEX0lETEUsICZzcCk7DQoNCiAgaWYgKG5p
Y2UobmljZWxldmVsKSA9PSAtMSkgew0KICAgIHBlcnJvcigibmljZSIpOw0K
ICAgIGV4aXQoMSk7DQogIH0NCg0KICBhcmd2Kys7DQogIGV4ZWN2KGFyZ3Zb
MF0sIGFyZ3YpOw0KDQogIHBlcnJvcigiZXhlYyIpOw0KICBleGl0KDEpOw0K
fQ0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCmRp
ZmYgLXVyIGxpbnV4L2luY2x1ZGUvbGludXgvc2NoZWQuaCAuL2luY2x1ZGUv
bGludXgvc2NoZWQuaA0KLS0tIGxpbnV4L2luY2x1ZGUvbGludXgvc2NoZWQu
aAlTYXQgTWFyIDI5IDAxOjA4OjE3IDE5OTcNCisrKyAuL2luY2x1ZGUvbGlu
dXgvc2NoZWQuaAlUaHUgQXByIDE3IDEzOjM1OjQ4IDE5OTcNCkBAIC05Myw2
ICs5Myw3IEBADQogI2RlZmluZSBTQ0hFRF9PVEhFUgkJMA0KICNkZWZpbmUg
U0NIRURfRklGTwkJMQ0KICNkZWZpbmUgU0NIRURfUlIJCTINCisjZGVmaW5l
IFNDSEVEX0lETEUJCTMNCiANCiBzdHJ1Y3Qgc2NoZWRfcGFyYW0gew0KIAlp
bnQgc2NoZWRfcHJpb3JpdHk7DQpAQCAtMjEwLDcgKzIxMSw4IEBADQogCXN0
cnVjdCB3YWl0X3F1ZXVlICp3YWl0X2NobGRleGl0OwkvKiBmb3Igd2FpdDQo
KSAqLw0KIAl1bnNpZ25lZCBzaG9ydCB1aWQsZXVpZCxzdWlkLGZzdWlkOw0K
IAl1bnNpZ25lZCBzaG9ydCBnaWQsZWdpZCxzZ2lkLGZzZ2lkOw0KLQl1bnNp
Z25lZCBsb25nIHRpbWVvdXQsIHBvbGljeSwgcnRfcHJpb3JpdHk7DQorCXVu
c2lnbmVkIGxvbmcgdGltZW91dCwgcG9saWN5Ow0KKwlsb25nIHJ0X3ByaW9y
aXR5Ow0KIAl1bnNpZ25lZCBsb25nIGl0X3JlYWxfdmFsdWUsIGl0X3Byb2Zf
dmFsdWUsIGl0X3ZpcnRfdmFsdWU7DQogCXVuc2lnbmVkIGxvbmcgaXRfcmVh
bF9pbmNyLCBpdF9wcm9mX2luY3IsIGl0X3ZpcnRfaW5jcjsNCiAJc3RydWN0
IHRpbWVyX2xpc3QgcmVhbF90aW1lcjsNCmRpZmYgLXVyIGxpbnV4L2tlcm5l
bC9zY2hlZC5jIC4va2VybmVsL3NjaGVkLmMNCi0tLSBsaW51eC9rZXJuZWwv
c2NoZWQuYwlUdWUgQXByICA4IDE3OjQ3OjQ3IDE5OTcNCisrKyAuL2tlcm5l
bC9zY2hlZC5jCVR1ZSBBcHIgMjkgMTg6Mjk6MzkgMTk5Nw0KQEAgLTEzODAs
NyArMTM4MCw3IEBADQogCWlmIChwb2xpY3kgPCAwKQ0KIAkJcG9saWN5ID0g
cC0+cG9saWN5Ow0KIAllbHNlIGlmIChwb2xpY3kgIT0gU0NIRURfRklGTyAm
JiBwb2xpY3kgIT0gU0NIRURfUlIgJiYNCi0JCSBwb2xpY3kgIT0gU0NIRURf
T1RIRVIpDQorCQkgcG9saWN5ICE9IFNDSEVEX09USEVSICYmIHBvbGljeSAh
PSBTQ0hFRF9JRExFKQ0KIAkJcmV0dXJuIC1FSU5WQUw7DQogCQ0KIAkvKg0K
QEAgLTEzOTksNyArMTM5OSwxNSBAQA0KIAkJcmV0dXJuIC1FUEVSTTsNCiAN
CiAJcC0+cG9saWN5ID0gcG9saWN5Ow0KLQlwLT5ydF9wcmlvcml0eSA9IGxw
LnNjaGVkX3ByaW9yaXR5Ow0KKw0KKwlpZiAocG9saWN5ID09IFNDSEVEX0lE
TEUpDQorICAgICAgCQkvKg0KKwkJICogbG9vayBpbnRvIGdvb2RuZXNzKCkg
YmVmb3JlIGNvbXBsYWluaW5nIDspDQorCQkgKi8NCisJCXAtPnJ0X3ByaW9y
aXR5ID0gLTE5OTkgKyBscC5zY2hlZF9wcmlvcml0eTsNCisJZWxzZQ0KKwkJ
cC0+cnRfcHJpb3JpdHkgPSBscC5zY2hlZF9wcmlvcml0eTsNCisNCiAJY2xp
KCk7DQogCWlmIChwLT5uZXh0X3J1bikNCiAJCW1vdmVfbGFzdF9ydW5xdWV1
ZShwKTsNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg==
---1247997369-209215680-908844973=:24868--

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/