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
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.
> >
> >
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
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
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 already
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
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. And usign
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 was
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
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
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
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
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 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
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 since
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 already depend on
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 other
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 notifiers that try
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
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
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,
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
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"
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
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
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
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
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 no
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
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
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 flag
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 other
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, so
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 the freezer
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 thing that
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 has to set in
38 matches
Mail list logo
