On Monday, 14 May 2007 09:26, Gautham R Shenoy wrote:
> On Mon, May 14, 2007 at 11:48:46AM +0530, Srivatsa Vaddagiri wrote:
> >
> > The other complication get/put_hotcpu() had was dealing with
> > write-followed-by-read lock attempt by the *same* thread (whilst doing
> > cpu_down/up). IIRC this w
On Mon, May 14, 2007 at 11:48:46AM +0530, Srivatsa Vaddagiri wrote:
> On Sun, May 13, 2007 at 09:33:41AM -0700, Linus Torvalds wrote:
> > On Sun, 13 May 2007, Gautham R Shenoy wrote:
> > > RFC #1: Use get_hot_cpus()- put_hot_cpus() , which follow the
> > > well known refcounting model.
> >
> > Yes
On Mon, May 14, 2007 at 11:48:46AM +0530, Srivatsa Vaddagiri wrote:
>
> The other complication get/put_hotcpu() had was dealing with
> write-followed-by-read lock attempt by the *same* thread (whilst doing
> cpu_down/up). IIRC this was triggered by some callback processing in
> CPU_DEAD
> or CP
On Sun, May 13, 2007 at 09:33:41AM -0700, Linus Torvalds wrote:
> On Sun, 13 May 2007, Gautham R Shenoy wrote:
> > RFC #1: Use get_hot_cpus()- put_hot_cpus() , which follow the
> > well known refcounting model.
>
> Yes. And usign the "preempt count" as a refcount is fairly natural, no?
> We do al
On Sunday, 13 May 2007 22:49, Linus Torvalds wrote:
>
> On Sun, 13 May 2007, Rafael J. Wysocki wrote:
> >
> > Besides, the problems with interdependencies that we've had recently are
> > related specifically to the CPU hotplug. To be precise, they are related
> > to the
> > CPU hotplug notifier
On Sun, 13 May 2007, Rafael J. Wysocki wrote:
>
> Besides, the problems with interdependencies that we've had recently are
> related specifically to the CPU hotplug. To be precise, they are related to
> the
> CPU hotplug notifiers that try to stop kernel threads which may be frozen.
> The othe
On Sunday, 13 May 2007 18:33, Linus Torvalds wrote:
>
> On Sun, 13 May 2007, Gautham R Shenoy wrote:
> >
> > RFC #1: Use get_hot_cpus()- put_hot_cpus() , which follow the
> > well known refcounting model.
>
> Yes. And usign the "preempt count" as a refcount is fairly natural, no?
> We do alread
On Sun, 13 May 2007, Gautham R Shenoy wrote:
>
> RFC #1: Use get_hot_cpus()- put_hot_cpus() , which follow the
> well known refcounting model.
Yes. And usign the "preempt count" as a refcount is fairly natural, no?
We do already depend on that in many code-paths.
It also has the advantage sin
Hi Linus,
I apologise for citing 'for_each_online_cpu()' as the reason, when
I actually was thinking about 'online_cpu_map'. That only proves
that I should not reply to stuff when I am sleepy!
Anyway, coming back to the freezer cpu hotplug part, cpu-hotplug locking
has been broken for almost a
Hi!
> > If you fail to do that, we'll see freezer failure, quickly, and catch
> > the simple bug.
>
> "It's a feature to add crap to drivers and subsystems that don't care!"
>
> That's a novel thing.
>
> Maybe we could add other features too. Like a "IM_NOT_AN_IDIOT" flag that
> every driver h
Hi,
On Saturday, 12 May 2007 21:17, Pavel Machek wrote:
> Hi!
>
> > Having considered the issue of freezing (or not freezing) kernel threads
> > for a
> > longer while I tend to agree with Linus that we shouldn't be freezing as
> > many
> > kernel threads as we currently freeze, but there's one
On Saturday, 12 May 2007 20:25, Linus Torvalds wrote:
>
> On Sat, 12 May 2007, Rafael J. Wysocki wrote:
> >
> > Of course, that would also require us to rewrite the freezer itself quite a
> > bit, but IMO it's worthy of doing.
> >
> > Thoughts?
>
> I'd much prefer it. One of the reasons I hate
On Sat, 12 May 2007, Linus Torvalds wrote:
>
> - make the rule be that you cannot sleep in the above macro, and make the
>rule be that CPU hotplug uses the same mechanisms that module unload
>already does!
Side note: we obviously already do the stop_machine_run thing for CPU
down, s
On Sun, 13 May 2007, Gautham R Shenoy wrote:
>
> With the "freeze-limited-kernel-threads" scheme, we would still need
> to perform this audit, since we now have to freeze only those kernel
> threads which *may* end up calling foo().
What the *heck* is wrong with just adding proper locking or ot
On Sat, 12 May 2007, Pavel Machek wrote:
>
> If you fail to do that, we'll see freezer failure, quickly, and catch
> the simple bug.
"It's a feature to add crap to drivers and subsystems that don't care!"
That's a novel thing.
Maybe we could add other features too. Like a "IM_NOT_AN_IDIOT" fl
On Sat, May 12, 2007 at 08:17:31PM +0200, Rafael J. Wysocki wrote:
> Hi,
>
> Having considered the issue of freezing (or not freezing) kernel threads for a
> longer while I tend to agree with Linus that we shouldn't be freezing as many
> kernel threads as we currently freeze, but there's one thing
Hi!
> Having considered the issue of freezing (or not freezing) kernel threads for a
> longer while I tend to agree with Linus that we shouldn't be freezing as many
> kernel threads as we currently freeze, but there's one thing that he doesn't
> seem to take into account. Namely, there may be som
On Sat, 12 May 2007, Rafael J. Wysocki wrote:
>
> Of course, that would also require us to rewrite the freezer itself quite a
> bit, but IMO it's worthy of doing.
>
> Thoughts?
I'd much prefer it. One of the reasons I hate the freezer so much is that
it ends up affecting things it really has
Hi,
Having considered the issue of freezing (or not freezing) kernel threads for a
longer while I tend to agree with Linus that we shouldn't be freezing as many
kernel threads as we currently freeze, but there's one thing that he doesn't
seem to take into account. Namely, there may be some kernel
19 matches
Mail list logo