Re: CFQ + 2.6.13-rc4-RT-V0.7.52-02 = BUG: scheduling with irqs disabled

From: Jens Axboe (axboe_at_suse.de)
Date: 08/25/05

  • Next message: Jens Axboe: "Re: 2.6.13-rc7: crash on removing CF card"
    Date:	Thu, 25 Aug 2005 13:17:19 +0200
    To: Ingo Molnar <mingo@elte.hu>
    
    

    On Thu, Aug 25 2005, Ingo Molnar wrote:
    >
    > * Jens Axboe <axboe@suse.de> wrote:
    >
    > > There can quite easily be lots of pending IO for the io_context (and,
    > > in CFQ's case, below cfq_io_contexts), task exiting is completely
    > > decoupled from any pending io.
    >
    > yes, but that only affects the io_context reference count. Actual new
    > use of tsk->io_context should only be possible on the IO-submission
    > side, which should all have stopped by the time we execute do_exit().
    > (and it's synchronous anyway, so the fact that we are executing in the
    > kernel prevents the same thread from submitting new IO, in this case.)
    >
    > i.e. the removal of tsk->io_context can be done without locking out
    > interrupts. No interrupt or io_context is supposed to access
    > current->io_context at that point.

    Well that's not quite correct, changes were made that allow lookup of
    the cic from another task. What happens is that process A will be
    dirtying lots of data and process B will be quitely reading other data.
    Process B can then get unlucky and have to do page reclaim on behalf of
    process A, simply because it tries to allocate a page under memory
    pressure.

    This is probably fairly rare, because async writeout goes to a dedicated
    queue typically bound to one (or more) of the pdflush threads which
    never exit. None the less, it needs fixing.

    This used to be safe (it used rcu and the cfq_cic_lock to protect read
    and write side respectively), I _think_ this was dropped at some point
    because I dropped the cross-lookup. I have to ponder how best to fix
    this...

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

  • Next message: Jens Axboe: "Re: 2.6.13-rc7: crash on removing CF card"

    Relevant Pages

    • Re: CFQ + 2.6.13-rc4-RT-V0.7.52-02 = BUG: scheduling with irqs disabled
      ... which should all have stopped by the time we execute do_exit. ... interrupts. ... I cannot even convince myself that it is currently safe right ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • APIC problems on VIA box
      ... I first noticed this on 2.6.0test3: on my Tyan KT133 SMP box all the interrupts ... LOC: 2314693 2314783 ... help debug the problem. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: Attempted summary of "RT patch acceptance" thread
      ... This even ignoring the fact all those context switch will not be cheap, ... on a embedded it can matter, so the more reliable solution is obviously ... linuxdevices to execute probably a 10% of that is wasted in the irq ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: Fw: [RFC] Strange code in cpu_idle()
      ... > What happens if the processor became aware of a new grace period just ... I could also imagine somehow deferring ... > interrupts until pm_idle exits. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: Query - Regarding strange behaviour.
      ... > I need your help/support. ... and execute `/sbin/fsck -f /` to force a check of the root file-system. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)