On Thu, 2009-03-19 at 23:23 +0100, Miklos Szeredi wrote:
> From: Miklos Szeredi
>
> This patch fixes bug #12208.
>
> This turned out to be not a scheduler regression, but an already
> existing problem in ptrace being triggered by subtle scheduler
> changes.
>
> The problem is this:
>
> - task
On Fri, 20 Mar 2009, Peter Zijlstra wrote:
> On Thu, 2009-03-19 at 23:23 +0100, Miklos Szeredi wrote:
> >
> > This patch solves this by not scheduling on preempt_enable() after
> > ptrace_stop() has woken up the tracer.
>
> Nice,.. however did you find this?
Ftrace helped a lot, it's a really co
* Miklos Szeredi wrote:
> On Fri, 20 Mar 2009, Peter Zijlstra wrote:
> > On Thu, 2009-03-19 at 23:23 +0100, Miklos Szeredi wrote:
> > >
> > > This patch solves this by not scheduling on preempt_enable() after
> > > ptrace_stop() has woken up the tracer.
> >
> > Nice,.. however did you find thi
* Miklos Szeredi wrote:
> On Fri, 20 Mar 2009, Peter Zijlstra wrote:
> > On Fri, 2009-03-20 at 10:43 +0100, Miklos Szeredi wrote:
> > > Ingo,
> > >
> > > I tested this one, and I think it makes sense in any case as an
> > > optimization. It should also be good for -stable kernels.
> > >
> > >
On 03/19, Roland McGrath wrote:
>
> I'm no scheduler expert and I don't know whether the exact placement in
> your change is the optimal one.
Agreed, can't we do a bit more simple patch?
--- kernel/signal.c
+++ kernel/signal.c
@@ -1572,8 +1572,10 @@ static void ptrace_stop
* Miklos Szeredi wrote:
> On Fri, 20 Mar 2009, Ingo Molnar wrote:
> > > > The first line of attack for this problem is making
> > > > wait_task_inactive() sucks less, which shouldn't be too hard,
> > > > that unconditional 1 jiffy sleep is simply retarded.
> > >
> > > I completely agree. How
On Thu, 19 Mar 2009, Roland McGrath wrote:
> I'm no scheduler expert and I don't know whether the exact placement in
> your change is the optimal one. But it's certainly fine from a ptrace
> perspective.
I'm no scheduler expert either.
Maybe a more generic solution in the scheduler (something li
On Fri, 20 Mar 2009, Peter Zijlstra wrote:
> On Fri, 2009-03-20 at 10:43 +0100, Miklos Szeredi wrote:
> > Ingo,
> >
> > I tested this one, and I think it makes sense in any case as an
> > optimization. It should also be good for -stable kernels.
> >
> > Does it look OK?
>
> The idea is good, bu
Ingo,
I tested this one, and I think it makes sense in any case as an
optimization. It should also be good for -stable kernels.
Does it look OK?
Thanks,
Miklos
From: Miklos Szeredi
This patch fixes bug #12208:
http://bugzilla.kernel.org/show_bug.cgi?id=12208
Don't preempt tasks in p
On Fri, 2009-03-20 at 10:43 +0100, Miklos Szeredi wrote:
> Ingo,
>
> I tested this one, and I think it makes sense in any case as an
> optimization. It should also be good for -stable kernels.
>
> Does it look OK?
The idea is good, but there is a risk of preemption latencies here. Some
code pat
On Fri, 20 Mar 2009, Ingo Molnar wrote:
> > > The first line of attack for this problem is making
> > > wait_task_inactive() sucks less, which shouldn't be too hard,
> > > that unconditional 1 jiffy sleep is simply retarded.
> >
> > I completely agree. However, I'd like to have a non-invasive
On 03/20, Miklos Szeredi wrote:
>
> I'm no scheduler expert either.
neither me ;)
> --- linux.git.orig/kernel/sched.c 2009-03-18 12:53:47.0 +0100
> +++ linux.git/kernel/sched.c 2009-03-20 08:58:13.0 +0100
> @@ -4629,7 +4629,8 @@ asmlinkage void __sched preempt_schedule
>
12 matches
Mail list logo
