--79888902-913465448-945509878=:935
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-ID: <Pine.LNX.4.10.9912181046131.1123@chiara.csoma.elte.hu>
On Fri, 17 Dec 1999, William Montgomery wrote:
> Would it be possible to do a resched in resched_idle since a decision
> for need_resched is made there anyway? Would this cause problems?
we basically do a reschedule in resched_idle(), but no, it cannot really
be done there - we must not schedule interrupts. I'm working on a scheme
that enables us to do a 'direct context switch' if reschedule_idle() is
preempting a process on any CPU - this prevents the goodness() loop in
schedule and prevents other problems as well [like the case where some CPU
'steals' a freshly woken up process.]. I'm preparing a set of patches that
fix these things, but this should not affect your problem though.
about the other entry.S need_resched race Jamie noticed, the attached
patch should fix both the signal and the need_resched race. (patch works
here just fine. You still need the separate idle thread fix.) This is a
very interesting bug category and it's a 2.2 problem as well so the same
fixes apply there too.
fixing up the return address from IRQ handlers is a faster but also more
complex solution (due to eg. vm86's different kernel stack layout). Unless
there is some subtle problem with it we should definitely use it in the
long term because otherwise we add 6 cycles overhead to every system call.
Lets first see wether we have found all places. Can you still see missed
reschedules?
-- mingo
--79888902-913465448-945509878=:935
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME="reschedfix-2.3.34-A0"
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.LNX.4.10.9912181037580.935@chiara.csoma.elte.hu>
Content-Description:
Content-Disposition: ATTACHMENT; FILENAME="reschedfix-2.3.34-A0"
LS0tIGxpbnV4L2FyY2gvaTM4Ni9rZXJuZWwvZW50cnkuUy5vcmlnCUZyaSBE
ZWMgMTcgMDc6NDg6MjQgMTk5OQ0KKysrIGxpbnV4L2FyY2gvaTM4Ni9rZXJu
ZWwvZW50cnkuUwlTYXQgRGVjIDE4IDAxOjIzOjM0IDE5OTkNCkBAIC0yMDcs
NiArMjA3LDcgQEANCiAJYW5kbCBTWU1CT0xfTkFNRShiaF9hY3RpdmUpLCVl
YXgNCiAJam5lIGhhbmRsZV9ib3R0b21faGFsZg0KIHJldF93aXRoX3Jlc2No
ZWR1bGU6DQorCWNsaQ0KIAljbXBsICQwLG5lZWRfcmVzY2hlZCglZWJ4KQ0K
IAlqbmUgcmVzY2hlZHVsZQ0KIAljbXBsICQwLHNpZ3BlbmRpbmcoJWVieCkN
CkBAIC0yMjIsNyArMjIzLDE2IEBADQogCWpuZSB2ODZfc2lnbmFsX3JldHVy
bg0KIAl4b3JsICVlZHgsJWVkeA0KIAljYWxsIFNZTUJPTF9OQU1FKGRvX3Np
Z25hbCkNCi0Jam1wIHJlc3RvcmVfYWxsDQorc2lnbmFsX3Jlc2NoZWQ6DQor
CWNsaQ0KKwljbXBsICQwLG5lZWRfcmVzY2hlZCglZWJ4KQ0KKwlqZSByZXN0
b3JlX2FsbA0KKwkvKg0KKwkgKiBkbyBub3QgcmVjdXJzZSBzaWduYWwgaGFu
ZGxlcnMuIFRoaXMgaXMgdGhlIHNsb3cgcGF0aC4NCisJICovDQorCXN0aQ0K
KwljYWxsIFNZTUJPTF9OQU1FKHNjaGVkdWxlKQ0KKwlqbXAgc2lnbmFsX3Jl
c2NoZWQNCiANCiAJQUxJR04NCiB2ODZfc2lnbmFsX3JldHVybjoNCkBAIC0y
MzAsNyArMjQwLDcgQEANCiAJbW92bCAlZWF4LCVlc3ANCiAJeG9ybCAlZWR4
LCVlZHgNCiAJY2FsbCBTWU1CT0xfTkFNRShkb19zaWduYWwpDQotCWptcCBy
ZXN0b3JlX2FsbA0KKwlqbXAgc2lnbmFsX3Jlc2NoZWQNCiANCiAJQUxJR04N
CiB0cmFjZXN5czoNCkBAIC0yNjksNiArMjc5LDcgQEANCiANCiAJQUxJR04N
CiByZXNjaGVkdWxlOg0KKwlzdGkNCiAJY2FsbCBTWU1CT0xfTkFNRShzY2hl
ZHVsZSkgICAgIyB0ZXN0DQogCWptcCByZXRfZnJvbV9zeXNfY2FsbA0KIA0K
--79888902-913465448-945509878=:935--
-
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/