On Wed, May 09, 2007 at 10:47:50AM +1000, Nick Piggin wrote:
>
> We've seen the same problem with other stop_machine_run sites in the kernel.
> module remove was one.
>
> Reserving the top priority slot for stop machine (and migration thread, I
> guess) isn't a bad idea.
I second this thought.
T
At Wed, 09 May 2007 10:47:50 +1000,
Nick Piggin wrote:
>
> Satoru Takeuchi wrote:
> > At Tue, 8 May 2007 22:18:50 +0530,
> > Srivatsa Vaddagiri wrote:
> >
> >>On Tue, May 08, 2007 at 04:16:06PM +0900, Satoru Takeuchi wrote:
> >>
> >>>Sometimes I wonder at prio_array. It has 140 entries(from 0 to
Satoru Takeuchi wrote:
At Tue, 8 May 2007 22:18:50 +0530,
Srivatsa Vaddagiri wrote:
On Tue, May 08, 2007 at 04:16:06PM +0900, Satoru Takeuchi wrote:
Sometimes I wonder at prio_array. It has 140 entries(from 0 to 139),
and the meaning of each entry is as follows, I think.
+---+---
At Tue, 8 May 2007 22:18:50 +0530,
Srivatsa Vaddagiri wrote:
>
> On Tue, May 08, 2007 at 04:16:06PM +0900, Satoru Takeuchi wrote:
> > Sometimes I wonder at prio_array. It has 140 entries(from 0 to 139),
> > and the meaning of each entry is as follows, I think.
> >
> > +---+---
On Tue, May 08, 2007 at 04:16:06PM +0900, Satoru Takeuchi wrote:
> Sometimes I wonder at prio_array. It has 140 entries(from 0 to 139),
> and the meaning of each entry is as follows, I think.
>
> +---+---+
> | index | usage
At Tue, 8 May 2007 09:40:33 +0530,
Srivatsa Vaddagiri wrote:
>
> On Tue, May 08, 2007 at 12:29:19PM +0900, Satoru Takeuchi wrote:
> > > We used to be able to create kernel threads higher than any userspace
> > > priority. If this is no longer true, I think that's OK: equal priority
> > > still me
On Tue, 2007-05-08 at 12:29 +0900, Satoru Takeuchi wrote:
> At Tue, 08 May 2007 13:02:25 +1000,
> Rusty Russell wrote:
> > We used to be able to create kernel threads higher than any userspace
> > priority. If this is no longer true, I think that's OK: equal priority
> > still means we'll get sche
On Tue, May 08, 2007 at 12:29:19PM +0900, Satoru Takeuchi wrote:
> > We used to be able to create kernel threads higher than any userspace
> > priority. If this is no longer true, I think that's OK: equal priority
> > still means we'll get scheduled, right?
>
> IF SCHED_RR, yes. However, if SCHED
At Tue, 08 May 2007 13:02:25 +1000,
Rusty Russell wrote:
>
> On Tue, 2007-05-08 at 11:41 +0900, Satoru Takeuchi wrote:
> > At Mon, 07 May 2007 23:42:53 +1000,
> > Rusty Russell wrote:
> > > I look forward to your patch!
> > > Rusty.
> >
> > Thanks, I'll do. Maybe this work will take several days
On Tue, 2007-05-08 at 11:41 +0900, Satoru Takeuchi wrote:
> At Mon, 07 May 2007 23:42:53 +1000,
> Rusty Russell wrote:
> > I look forward to your patch!
> > Rusty.
>
> Thanks, I'll do. Maybe this work will take several days including test.
Excellent.
> BTW, how should I manage rt process having
At Mon, 07 May 2007 23:42:53 +1000,
Rusty Russell wrote:
>
> On Mon, 2007-05-07 at 19:10 +0900, Satoru Takeuchi wrote:
> > Hi,
> >
> > I found a bug on 2.6.21 cpu-hotplug code.
> >
> > When process A on CPU0 try to offline the CPU1 on which the process B,
> > realtime process (its task->policy =
On Mon, 2007-05-07 at 19:10 +0900, Satoru Takeuchi wrote:
> Hi,
>
> I found a bug on 2.6.21 cpu-hotplug code.
>
> When process A on CPU0 try to offline the CPU1 on which the process B,
> realtime process (its task->policy == SCHED_FIFO or SCHED_RR) running
> without sleep or yield, both CPU0 and
On Mon, May 07, 2007 at 04:32:56PM +0530, Srivatsa Vaddagiri wrote:
> On Mon, May 07, 2007 at 04:17:24PM +0530, Gautham R Shenoy wrote:
> > Nevertheless, with the freezer based approach that we're experimenting,
> > this problem shouldn't arise. We expect the whole system to get frozen
> > before w
On Mon, 07 May 2007 19:10:05 +0900
Satoru Takeuchi <[EMAIL PROTECTED]> wrote:
> kstopmachine is created, bound to the CPU1, and woken up here, but
> this process can't start to run because reschedule doesn't occur on
> CPU1. Hence CPU0 also be able to run because it's waiting completion
> of CPU1
On Mon, May 07, 2007 at 04:17:24PM +0530, Gautham R Shenoy wrote:
> Nevertheless, with the freezer based approach that we're experimenting,
> this problem shouldn't arise. We expect the whole system to get frozen
> before we actually do a cpu_down() (which will then call
> __stop_machine_run). So a
On Mon, May 07, 2007 at 07:10:05PM +0900, Satoru Takeuchi wrote:
> Hi,
>
> I found a bug on 2.6.21 cpu-hotplug code.
>
> When process A on CPU0 try to offline the CPU1 on which the process B,
> realtime process (its task->policy == SCHED_FIFO or SCHED_RR) running
> without sleep or yield, both CP
Hi Satoru,
On Mon, May 07, 2007 at 07:10:05PM +0900, Satoru Takeuchi wrote:
> Hi,
>
> I found a bug on 2.6.21 cpu-hotplug code.
IIRC, __stop_machine_run is used by subsystems other than cpu-hotplug.
So we're not the only ones bugged.
>
> When process A on CPU0 try to offline the CPU1 on which
17 matches
Mail list logo
