Messages in this thread | | | Date | Fri, 11 Dec 2009 18:33:33 +0100 | From | Pavel Machek <> | Subject | Re: [PATCH] ACPICA: don't cond_resched() when irq_disabled or in_atomic |
| |
On Thu 2009-12-10 21:37:59, Alexey Starikovskiy wrote: > Pavel Machek ??????????: > > On Thu 2009-12-10 20:58:45, Alexey Starikovskiy wrote: > > > >> Hi Pavel, > >> > >> Please elaborate... Your comments "ugly as hell" are too often to be > >> specific... > >> There is only one use of ACPI_PREEMPTION_POINT(), and it is in the > >> ACPICA code, > >> which we all agreed to keep OS independent, thus the need for #define. > >> Do you see any other way to add preemption point without introducing > >> Linux-specific > >> code into ACPICA? > >> > > > > I believe we want linux-specific code in acpica at this point. > > > > > The point there we call cond_resched() in ACPICA is an interpreter parse > loop. This parse loop may be executed from within atomic context and even > with interrupts off. In this case, cond_resched() should not be called > to not make > might_sleep() guards angry.
Yes, so pass explicit argument to the interpretter, telling it what kind of context it runs on. Similar to kmalloc's GFP_KERNEL vs. GFP_ATOMIC. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
| |