>I don't think the _idea_ is crap per se, but it would at a >minimum need a >thread limit. But I think it's the wrong approach: especially >if you put >the current thread to sleep, you really don't want another >thread at all, >you are really just working around a problem that is totally >internal to >acpi (and the AML interpreter in particular). Agree, this was meant as a temporary fix while we make interpreter to be able to preempt, as you suggesting later. > >So I think the problem really lies elsewhere, and that the >whole thread >approach was trying to paper over it. And having a limited set >of threads >is probably potentially _worse_ then what we have now. Right now we have overheating NX and NC series of notebooks from HP with AMD processors (somehow Intel DSDTs do not use Notify from infinite While loop), plus several "kacpid uses 100% of cpu" caused by Notify() events, which were scheduled to rush through the queue if the bloker exits. > >Is there no way to have the AML interpreter have some state, >and just push >that current interrupted state back onto the "event queue", >and just start executing the new one instead? This interpreter cannot do such tricks and if we choose to executer Notify() immidiately on the same stack we risk to overflow it... > That sounds like it should fix the _real_ >problem - a kind of "mini-scheduler" for ACPI events? Yes, that will be a perfect solution, but it will require whole interpreter rewrite, so will take time. > > Linus > Thanks, Alex. - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
