lkml.org 
[lkml]   [2009]   [Dec]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [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


    \
     
     \ /
      Last update: 2009-12-11 18:37    [W:0.076 / U:0.304 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site