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
>
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 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, 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
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
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
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.
Thanks,
Roland
--
Apps built with the Adobe(R) Flex(R) framework
