Re: PATCH [PPC64]: dead processes never reaped

From: Benjamin Herrenschmidt (benh_at_kernel.crashing.org)
Date: 04/19/05

  • Next message: Greg KH: "[GIT PATCH] USB updates for 2.6.12-rc2" 
    To: Linas Vepstas <linas@austin.ibm.com>
Date:	Tue, 19 Apr 2005 11:07:01 +1000

    On Mon, 2005-04-18 at 14:38 -0500, Linas Vepstas wrote:
    >
    > Hi,
    >
    > The patch below appears to fix a problem where a number of dead processes
    > linger on the system. On a highly loaded system, dozens of processes
    > were found stuck in do_exit(), calling thier very last schedule(), and
    > then being lost forever.
    >
    > Processes that are PF_DEAD are cleaned up *after* the context switch,
    > in a routine called finish_task_switch(task_t *prev). The "prev" gets
    > the value returned by _switch() in entry.S, but this value comes from
    >
    > __switch_to (struct task_struct *prev,
    > struct task_struct *new)
    > {
    > old_thread = &current->thread; ///XXX shouldn't this be prev, not current?
    > last = _switch(old_thread, new_thread);
    > return last;
    > }
    >
    > The way I see it, "prev" and "current" are almost always going to be
    > pointing at the same thing; however, if a "need resched" happens,
    > or there's a pre-emept or some-such, then prev and current won't be
    > the same; in which case, finish_task_switch() will end up cleaning
    > up the old current, instead of prev. This will result in dead processes
    > hanging around, which will never be scheduled again, and will never
    > get a chance to have put_task_struct() called on them.

    Ok, thinking moer about this ... that will need maybe some help from
    Ingo so I fully understand where schedule's are allowed ... We are
    basically in the middle of the scheduler here, so I wonder how much of
    the scheduler itself can be preempted or so ...

    Basically, under which circumstances can prev and current be different ?

    Ben.

    -
    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: Greg KH: "[GIT PATCH] USB updates for 2.6.12-rc2"

    Relevant Pages

    • Re: PATCH [PPC64]: dead processes never reaped
      ... > The patch below appears to fix a problem where a number of dead processes ... don't see any codepath where prev!= current before switch_to. ... switch the entire context, including stack, and thus including the value ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: PATCH [PPC64]: dead processes never reaped
      ... >> The patch below appears to fix a problem where a number of dead processes ... Naively, we could rturn "prev", this would save a few ... conservative with the patch, ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • PATCH [PPC64]: dead processes never reaped
      ... The patch below appears to fix a problem where a number of dead processes ... On a highly loaded system, ... "prev" and "current" are almost always going to be ... This patch fixes this. ...
      (Linux-Kernel)
    • Re: PATCH [PPC64]: dead processes never reaped
      ... >> The patch below appears to fix a problem where a number of dead processes ... >> linger on the system. ... On a highly loaded system, ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: PATCH [PPC64]: dead processes never reaped
      ... > The patch below appears to fix a problem where a number of dead processes ... On a highly loaded system, ... > were found stuck in do_exit, calling thier very last schedule(), and ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)