h 4/4: Eliminates the CPU_DEAD and CPU_UP_CANCELLED event handling
from workqueue.c
The patch series has survived an overnight test with kernbench on i386.
and has been tested with Paul Mckenney's latest preemptible rcu code.
Awaiting thy feedback!
Thanks and Regards
gautham.
--
Gautha
] sysenter_past_esp+0x5f/0x99
===
--->
From: Gautham R Shenoy <[EMAIL PROTECTED]>
Some of the per-cpu counters and thus their locks
are accessed from IRQ contexts. This can cause a deadlock
if it interrupts a cpu-offline thread which is transferring
a dead-cpu's c
6/0x39 [rcutorture]
[] rcu_torture_fakewriter+0x4d/0xc5 [rcutorture]
rcu_random() can do with raw_smp_processor_id() as a parameter to cpu_clock()
in this particular context.
Signed-off-by: Gautham R Shenoy <[EMAIL PROTECTED]>
---
kernel/rcutorture.c |3 ++-
1 file changed, 2 insertions(+)
On Fri, Oct 05, 2007 at 08:24:21AM -0400, Steven Rostedt wrote:
>
>
>
> On Fri, 5 Oct 2007, Gautham R Shenoy wrote:
>
> > On Mon, Sep 10, 2007 at 11:39:01AM -0700, Paul E. McKenney wrote:
> >
> > [snip]
> >
> > > +
> > > +/*
&
list_add_tail(&p->run_list, ¤t->run_list);
> p->array = current->array;
> p->array->nr_active++;
> @@ -3590,6 +3592,8 @@ asmlinkage void __sched schedule(void)
> }
> profile_hit(SCH
>
> /*
> diff -urpNa -X dontdiff linux-2.6.22-E-hotplug/kernel/rtmutex.c
> linux-2.6.22-F-boostrcu/kernel/rtmutex.c
> --- linux-2.6.22-E-hotplug/kernel/rtmutex.c 2007-07-08 16:32:17.0
> -0700
> +++ linux-2.6.22-F-boostrcu/kernel/rtmutex.c 2007-08-24 11:24:59.000
On Wed, Aug 29, 2007 at 02:52:04PM +0400, Oleg Nesterov wrote:
> On 08/29, Gautham R Shenoy wrote:
> >
> > On Tue, Aug 28, 2007 at 05:48:53PM +0400, Oleg Nesterov wrote:
> > > (cpu-hotplug experts cc'ed)
> > >
> > > On 08/25, Oleg Nesterov wrote:
the cpus while
they are in the offlined state. And on cpu_up, if the cpu is present in
the task's allowed mask, it can run on that cpu, which is a good thing.
The two users of cpuset_cpus_allowed - sched_setaffinity and pdflush
don't seem to require the online cpu information.
Paul,
fferent platforms as well.
It's a good idea to add that info to the MAINTAINERS file as well.
Thanks and Regards
gautham.
--
Gautham R Shenoy
Linux Technology Center
IBM India.
"Freedom comes with a price tag of responsibility, which is still a bargain,
because Freedom is pric
he
side effect so critical, that we continue with this funny contradiction in
the kernel?! Or is there something important, I'm missing here?
>
> > Look at it this way. If we were to merge this patch then it would be
> > logical to also merge a patch which has the following desc
your paranoia, but let me assure you, you are
not the only one ;-)
Regards
gautham.
>
> Thanx, Paul
--
Gautham R Shenoy
Linux Technology Center
IBM India.
"Freedom comes with a price tag of responsibility, which is still a bargain,
because Fr
On Thu, Aug 23, 2007 at 06:15:01AM -0700, Paul E. McKenney wrote:
> On Thu, Aug 23, 2007 at 03:44:44PM +0530, Gautham R Shenoy wrote:
> > On Thu, Aug 23, 2007 at 01:54:56AM -0700, Paul E. McKenney wrote:
> > > On Thu, Aug 23, 2007 at 09:56:39AM +0530, Gautham R Shenoy wrote:
not set
# CONFIG_LIBCRC32C is not set
CONFIG_ZLIB_INFLATE=y
CONFIG_PLIST=y
CONFIG_HAS_IOMEM=y
CONFIG_HAS_IOPORT=y
CONFIG_HAS_DMA=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_X86_SMP=y
CONFIG_X86_HT=y
CONFIG_X86_BIOS_REBOOT=y
CONFIG_X86_TRAMPOLINE=y
CONFIG_KTIM
On Thu, Aug 23, 2007 at 01:54:56AM -0700, Paul E. McKenney wrote:
> On Thu, Aug 23, 2007 at 09:56:39AM +0530, Gautham R Shenoy wrote:
> >
> > I feel we should still be able to use for_each_online_cpu(cpu) instead
> > of for_each_possible_cpu. Again, there's a good
#x27;s statistics to
* this_rbdp here.
*/
put_cpu();
return NOTIFY_OK;
}
}
Won't this work in this case?
Thanks and Regards
gautham.
--
Gautham R Sh
On Thu, Aug 09, 2007 at 09:03:53PM +0400, Oleg Nesterov wrote:
> On 08/07, Oleg Nesterov wrote:
> >
> > On 08/07, Gautham R Shenoy wrote:
> > >
> > > A will now call kthread_bind(B, cpu1).
> > > kthread_bind(), calls wait_task_inactive(B), to ensu
set_prio(p, current->prio);
yield();
/* Reset priority back to the original value */
set_prio(p, old_prio);
}
Thoughts?
Thanks and Regards
gautham.
--
Gautham R Shenoy
Linux Technology Center
IBM India.
"Freedom comes with a price tag of responsibility
patch should do
> it.
>
> Signed-off-by: Dhaval Giani <[EMAIL PROTECTED]>
> Signed-off-by: Gautham Shenoy R <[EMAIL PROTECTED]>
Gautham R Shenoy
>
>
> Index: linux-2.6.23-rc1/mm/memcontrol.c
> =
goto bad;
> +if (!alien) {
> + kfree(shared);
> + kfree(nc);
> + goto bad;
> + }
> }
> cachep->
-1, &nr_calls);
> if (ret == NOTIFY_BAD) {
> + nr_calls--;
> printk("%s: attempt to bring up CPU %u failed\n",
> __FUNCTION__, cpu);
> ret = -EINVAL;
> -
> To unsubscri
g model to allow blocking code sections too, we cannot
use preempt_enable/disable.
Therefore sir, we do need nice scalable refcounting model :)
> As mentioned, it's actually fairly easy to add verification calls to make
> sure that certain accesses are done with preemption disabled, so..
>
>
; to cpu_online_map way back when cpu hotplug was being developed. It will
> be a good idea to reintroduce that back.
>
Yes. However, there are places where people keep a local copy of
the cpu_online_map. So any access to this local copy is also not
cpu-hotplug safe. No ?
> > and it
way. If you still feel that we can solve it using
a simpler, cleaner better method, I am all for it.
Why, even I would like to see this problem fixed, as much as you do,
if not more :-)
Thanks and Regards
gautham.
--
Gautham R Shenoy
Linux Technology Center
IBM India.
"Freedom comes with a price
e() from the remaining
> kernel threads. Later, if testing shows that we've overlooked some kernel
> threads which need to be made freezable, we'll be able to add the "ability to
> freeze" to these threads quite easily.
>
> Of course, that would also require u
op this patch and try to address the
> issue in the next series of patches.
I think it's a good idea.
I would want to review the patches again. The more I look at them,
the better I seem to understand the subtleties in the freezer code.
>
> Greetings,
> Rafael
Thanks and R
On Sat, May 12, 2007 at 11:27:36AM +0200, Rafael J. Wysocki wrote:
> On Saturday, 12 May 2007 10:16, Gautham R Shenoy wrote:
> >
> > But I am not sure if this is the case with suspend/hibernate, since we
> > need to do a sys_sync() between try_freeze_tasks(F
_to_freeze.
I won't expect an exiting thread to call try_to_freeze, but a
daemonize()ed thread can.
So should we perform that check in reparent_to_kthreadd() ?
We are protected by the tasklist_lock there, no?
>
> Rafael
Thanks and Regards
gautham.
--
Gautham R Shenoy
Linux Techno
On Wed, May 09, 2007 at 03:20:47PM +0200, Stefan Richter wrote:
> Gautham R Shenoy wrote:
> > freezer_exempt() as of now does what its name says. I.e, exempt the
> > thread from all kinds of freeze chills.
> >
> > But with more subsystems using the process freezer, th
f freeze chills.
But with more subsystems using the process freezer, the exemption needs
to be event specific. There may be threads which should not be frozen
for say kprobes, should be frozen for cpu-hotplug. This selective
freezing is not yet available. But it will be soon...
> --
> Stefan
idea.
I second this thought.
The process freezer, if used will only safeguard cpu-hotplug, but not other
sites which use stop_machine_run.
>
> --
> SUSE Labs, Novell Inc.
Regards
gautham.
--
Gautham R Shenoy
Linux Technology Center
IBM India.
"Freedom comes with a price tag o
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
ich it will), but that's ok, since on a freezer-fail,
we just thaw all the processes and get the system up and running again.
Yeah, the cpu-hotplug operation will fail though.
>
> Thanks,
>
> Sat
Regards
gautham.
--
Gautham R Shenoy
Linux Technology Center
IBM India
see cpu0 to cpu77 in the sysfs entries on the
lpar which I was using. Looking at the kernel code, I figured out that
the MAX_CPUS for that lpar was 39 and each virtual cpu was probably
running 2 threads. That explained the 78 sysfs entries.
Thanks for the explaination anyway.
Regards
gautha
y intentional ?
Or is it due to the fact that in most cases,
cpu_present_map == cpu_possible_map, so lets not bother about it :-?
Thanks and Regards
gautham.
--
Gautham R Shenoy
Linux Technology Center
IBM India.
"Freedom comes with a price tag of responsibility, which is still a bargain,
beca
sses(void)
> > +void thaw_processes(unsigned long thaw_event)
> > {
> > + mutex_lock(&freezer_mutex);
> > + if (!(system_frozen_event_mask & thaw_event)) {
> > + WARN_ON(1);
>
> Hmm, I wouldn't use the WARN_ON() here. There'
tasks()
called in CPU_DEAD handling of migration_call (kernel/sched.c).
So we are safe. Anyway, I apologise for causing any worry :-)
Thanks and Regards
gautham.
>
>
>
> From: Gautham R Shenoy <[EMAIL PROTECTED]>
>
> We are anyway kthread_stop()ping other per-cpu kernel th
On Fri, Apr 27, 2007 at 11:22:22PM -0700, Andrew Morton wrote:
> On Sat, 28 Apr 2007 07:04:46 +0530 Gautham R Shenoy <[EMAIL PROTECTED]> wrote:
>
> > This patch
> > * Provides an interface to selectively freeze the system for different
> > events.
> > * Allows
hotplug would start
using the process freezer, where EVENT_A would be SUSPEND and EVENT_B
would be HOTPLUG_CPU.
This patch applies on the top of 2.6.21-rc7-mm2 + Rafael's freezer
changes from http://lkml.org/lkml/2007/4/27/302.
Signed-off-by: Gautham R Shenoy <[EMAIL PROTECTED]>
---
arch/
> I guess so.
>
> > Else it throws the following warnings.
>
> On which arch is that? I've tested on x86_64 ...
I compile tested it on i386 with gcc v4.1.2.
>
>
> Greetings,
> Rafael
Regards
gautham.
--
Gautham R Shenoy
Linux Technology Center
IBM India
g 2 of
`constant_test_bit' from incompatible pointer type
include/linux/freezer.h:152: warning: passing arg 2 of
`variable_test_bit' from incompatible pointer type
Regards
gautham.
--
Gautham R Shenoy
Linux Technology Center
IBM India.
"Freedom comes with a price tag of responsibili
e_flag(p);
That means something else. clear_freeze_flag() just clears the
TFF_FREEZE flag and not necessarily everything.
Besides, this is the only place where we would need to clear all the bits
of p->freezer_flags. Not sure if having a static inline helper function
is worth it.
>
>
On Thu, Apr 26, 2007 at 04:36:09PM +0400, Oleg Nesterov wrote:
> On 04/26, Gautham R Shenoy wrote:
> >
> > Other than refrigerator, no one else calls frozen_process(). So move it from
> > include/linux/freezer.h to kernel/power/process.c.
>
> Could you also remove th
ask_struct *p) parameter to frozen_process().
Signed-off-by: Gautham R Shenoy <[EMAIL PROTECTED]>
---
include/linux/freezer.h | 12
kernel/power/process.c | 14 +-
2 files changed, 13 insertions(+), 13 deletions(-)
Index: linux-2.6.21-rc7/incl
d_cpu(), so we can do it with the stop_machine_run
thread as well.
I just checked with Vatsa if there was any subtle reason why they
had put in the kthread_bind() in cpu.c. Vatsa cannot seem to recollect
any and I can't see any. So let us just remove the kthread_bind.
Signed-off-by: Gaut
kernel/kthread.c line 161)
We only need to ensure in kthread_bind that the task which is being
bound is not running or exiting. Doesn't matter if it's sleeping in
TASK_INTERRUPTIBLE or TASK_UNINTERRUPTIBLE state.
Signed-off-by: Gautham R Shenoy <[EMAIL PROTECTED]>
---
kernel/k
We
> know there's one locking bug which manifests in the bare net-2.6.22 tree,
> and I'm suspecting that there are other (albeit perhaps related) locking
> bugs triggered by something else in -mm. Something which precedes
> git-net.patch in the series file (ie: anothe
c036f520 c9094e40 c036f4e0
> 0246
> c9094e60 c0299cc7 0002 c0299dfe c965614c
> c6f45550
> Call Trace:
> [__mutex_lock_slowpath+330/610] __mutex_lock_slowpath+0x14a/0x262
> [mutex_lock+31/35] mutex_lock+0x1f/0x23
> [rtnl_
path ?
>
> Yes, thanks for pointing that out.
That reminds me, shouldn't we set the child's TFF_FREEZE flag if the parent
is freezing or frozen?
>
> Should I clear it in dup_task_struct() or is there a better place?
Thanks and Regards
gautham.
--
Gautham R Shenoy
Linux Techno
On Tue, Apr 24, 2007 at 12:46:37AM +0400, Oleg Nesterov wrote:
> On 04/23, Rafael J. Wysocki wrote:
> >
> > On Monday, 23 April 2007 14:35, Gautham R Shenoy wrote:
> > > > + if (!freezer_should_exempt(current)) {
> > > task_lock(k);
> > &
On Mon, Apr 23, 2007 at 10:39:56PM +0400, Oleg Nesterov wrote:
> On 04/23, Gautham R Shenoy wrote:
> >
> > On Sat, Apr 21, 2007 at 01:12:09AM +0400, Oleg Nesterov wrote:
> > > On 04/19, Gautham R Shenoy wrote:
> > > >
> > >
eep, like wait_for_completion. */
freezer_count(current);
Once the task wakes up from it's uninterruptible sleep, it will
call freezer_count which in turn calls try_to_freeze.
If the task was marked for freezing, it will be frozen now.
You may want to check the thread http://lkml.org/lkml/2007/2/
_flag(p);
> wmb();
> - clear_tsk_thread_flag(p, TIF_FREEZE);
> + do_not_freeze(p);
We may want to rename do_not_freeze to something else. It kind of
looks weird calling do_not_freeze(p) after setting the frozen flag!
Probably, just a matter of taste :-)
> }
>
Thanks and Regards
gautham.
-
d being
> + * stopped is not frozen and will not be frozen until it dies
> + */
> + freezer_exempt(k);
> + if (frozen(k))
> + clear_frozen_flag(k);
task_unlock(k);
> + }
Thanks and Regards
gautham.
--
Gautham R
On Sat, Apr 21, 2007 at 01:12:09AM +0400, Oleg Nesterov wrote:
> On 04/19, Gautham R Shenoy wrote:
> >
> > @@ -63,12 +74,16 @@ void refrigerator(void)
> > recalc_sigpending(); /* We sent fake signal, clean it up */
> > spin_unlock_irq(¤t->sighand->siglock)
On Fri, Apr 20, 2007 at 10:02:08PM +0400, Oleg Nesterov wrote:
> On 04/19, Rafael J. Wysocki wrote:
> >
> > On Thursday, 19 April 2007 14:02, Gautham R Shenoy wrote:
> > > This patch fixes the race pointed out by Oleg Nesterov.
> > >
> > > * Freezer
t will make
> up almost a separate u8 field ...
I am perfectly ok with it. But I am not sure if everybody would agree to have
another field in the task struct, though in this case it does make sense :-)
>
> Greetings,
> Rafael
> -
Thanks and Regards
gautham.
--
Gautham R Shenoy
Linux
tion would be for A to
somehow inform B of the dependency and postpone it's freezing.
Since akpm mentioned that flush_workqueue() needs to go, I guess, I am
ok with fixing only kthread_stop/kthread_should_stop for the moment.
Unless I can spot any other valid case :)
> wake_up_proce
On Thu, Apr 19, 2007 at 02:31:33PM -0700, Andrew Morton wrote:
> On Thu, 19 Apr 2007 17:34:19 +0530
> Gautham R Shenoy <[EMAIL PROTECTED]> wrote:
>
>
> flush_workqueue() just needs to die. I think there are (almost) no
> legitimate users of it once cancel_work_sync(
il to thaw the task since it is
marked PF_NOFREEZE.
Avoid this problem by checking the current task's PF_NOFREEZE status in the
refrigerator before marking current as frozen.
Signed-off-by: Gautham R Shenoy <[EMAIL PROTECTED]>
---
kernel/power/process.c |9 +
1
es to call try_to_freeze.
kthread_stop is one such case. flush_workqueue might be another.
This patch attempts to address such a situation with a fix for kthread_stop.
Strictly experimental. Compile tested on i386.
Signed-off-by: Gautham R Shenoy <[EMAIL PROTECTED]>
---
include/asm-arm/th
,
Regards
gautham.
--
Gautham R Shenoy
Linux Technology Center
IBM India.
"Freedom comes with a price tag of responsibility, which is still a bargain,
because Freedom is priceless!"
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
++
> arch/i386/kernel/cpuid.c |2 ++
[snip]
Though I am wondering what might be the usecase for microcode!
Guess we'll see that patch soon :-)
Regards
gautham.
--
Gautham R Shenoy
Linux Technology Center
IBM India.
"Freedom comes with a price tag of responsibili
state = xxx_start(p);
... wait for something which depends on p...
xxx_end(state);
However, now that I look at it again, I see that it will fail in our case
where we might need to nest the try_to_freeze_tasks call.
Hmm, we don't have a rwlock variant that allows multiple wr
Of course, we can always use the freezer_skip around this
wait_for_completion as well as long as the thread A is not marked
PF_NOFREEZE. But with multiple freeze events, it won't be as simple as
that.
> --
> Regards,
> vatsa
Thanks and Regards
gautham.
--
Gautham R Shenoy
Linux T
On Wed, Apr 11, 2007 at 03:48:05PM +0400, Oleg Nesterov wrote:
> On 04/11, Gautham R Shenoy wrote:
> >
> > On Wed, Apr 11, 2007 at 12:13:34PM +0200, Rafael J. Wysocki wrote:
> > >
> > > It should be calling try_to_freeze() somewhere anyway. We may need to
>
zeable by default.
>From cpu-hotplug perspective, helper_wq was the only singlethreaded
non-freezeable workqueue.
>
> Greetings,
> Rafael
> -
Thanks and Regards
gautham.
--
Gautham R Shenoy
Linux Technology Center
IBM India.
"Freedom comes with a price tag of responsibility, whic
no longer true after this patch... Ugly ifdef above makes sure
> freezer is there for kprobes. I'm trying to say that #if above is
> now broken. Actually it was probably always broken, but it just became
> more so.
I have already removed it from in my version 3.
Thanks and Regards
Gautham, this is code which we can cheerfully delete when we get
> the freezer stuff done. Fortunately, Anil's patch will make it nice and
> easy to find again.
Ok, I will make a note of this one.
If the IO-test results are good, I hope to post the patchset sometime
this week.
Thank
On Thu, Apr 05, 2007 at 02:53:56PM +0400, Oleg Nesterov wrote:
> On 04/02, Gautham R Shenoy wrote:
> >
> > + if (freeze_processes(FE_HOTPLUG_CPU)) {
> > + thaw_processes(FE_HOTPLUG_CPU);
> > + return -EBUSY;
> > + }
>
> Off-topic. Thi
On Thu, Apr 05, 2007 at 01:46:33PM +0400, Oleg Nesterov wrote:
> On 04/02, Gautham R Shenoy wrote:
> >
> > +/*
> > + * Exempt the current process from being frozen for a certain event
> > + */
> > +static inline void freezer_exempt(unsigned long exemp
On Thu, Apr 05, 2007 at 01:53:01PM +0400, Oleg Nesterov wrote:
> On 04/02, Gautham R Shenoy wrote:
> >
> > int freeze_processes(unsigned long freeze_event)
> > {
> > unsigned int nr_unfrozen;
> > -
> > + int ret = 0;
> > + mutex_lock(&fre
d/write in a tight loop should do the trick.
Will get back soon.
>
> Ingo
Thanks and Regards
gautham.
--
Gautham R Shenoy
Linux Technology Center
IBM India.
"Freedom comes with a price tag of responsibility, which is still a bargain,
because Freedom is priceless!"
-
To unsubscr
Ingo
Thanks and Regards
gautham.
--
Gautham R Shenoy
Linux Technology Center
IBM India.
"Freedom comes with a price tag of responsibility, which is still a bargain,
because Freedom is priceless!"
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" i
it in the -mm.
With that fix, freezer and hence hotplug succeeds even when I am running
a 'make -j' test.
>
> --
> Regards,
> vatsa
Thanks and Regards
gautham.
--
Gautham R Shenoy
Linux Technology Center
IBM India.
"Freedom comes with a price tag of responsibility, w
}
} else {
Seems to be missing in the latest -mm's.
Rafael / Andrew,
Any reasons for leaving this hunk out?
I will rerun my tests with this hunk applied and report back.
>
> Ingo
Thanks and Regards
gautham.
--
Gautham R Shenoy
Linux Technology Center
IBM
tracehook_report_vfork_done(p, nr);
}
} else {
Rafael / Andrew,
Any reasons for leaving this hunk out?
I reran my tests with this hunk applied, and it work just fine.
Even 'make -j' the maximum time taken to hotplug a cpu was 0m2.16s.
>
> Ingo
Tha
s all
> > > tasks which were previously marked PF_NOFREEZE are now
> > > exempted from freezer using
> > > freezer_exempt(FE_ALL);
> > > which means exempt from all kinds of freezes.
> > >
> > > Signed-off-by: Gautham R Shenoy <[EMAIL PRO
"not waiting
> for everyone to /voluntarily/ quiece" can break cpu hotplug. In fact,
> the biggest reason why we are moving to freezer based hotplug is the
> fact that it quiesces everyone, leading to (hopefully) zero race conditions.
>
> --
> Regards,
> vats
On Mon, Apr 02, 2007 at 08:16:12AM +0200, Ingo Molnar wrote:
>
> * Gautham R Shenoy <[EMAIL PROTECTED]> wrote:
>
> > Hello Everybody,
> >
> > This is another attempt towards process-freezer based cpu-hotplug.
> > This patchset covers just about everyth
in 'make -j' might be a
little too ambitious at this point of time. Atleast in my case it was :-)
The patchset is against 2.6.21-rc5-mm3.
Awaiting your feedback.
Thanks and Regards
gautham.
--
Gautham R Shenoy
Linux Technology Center
IBM India.
"Freedom comes with a price tag of
all non-singlethreaded workqueues *have* to
be frozen to avoid any races.
Signed-off-by: Gautham R Shenoy <[EMAIL PROTECTED]>
Signed-off-by: Srivatsa Vaddagiri <[EMAIL PROTECTED]>
Cc: Oleg Nesterov <[EMAIL PROTECTED]>
--
kernel/
This patch makes all the kernel_threads (except the migration thread)
freezeable for cpu hotplug.
Signed-off-by: Gautham R Shenoy <[EMAIL PROTECTED]>
--
arch/i386/kernel/apm.c |2 +-
drivers/block/loop.c|2 +-
drivers/char/apm-emulation.c
flush_workqueue in vain, in a frozen context.
Note:
o The singlethreaded workqueues will not be frozen.
Signed-off-by: Gautham R Shenoy <[EMAIL PROTECTED]>
Cc: Oleg Nesterov <[EMAIL PROTECTED]>
Cc: Johannes Berg <[EMAIL PROTECTED]>
--
include/linux/workqueue.h | 12 ++
This patch rips out lock_cpu_hotplug from the kernel.
Good Riddance!! (hopefully :) )
Signed-off-by : Gautham R Shenoy <[EMAIL PROTECTED]>
--
arch/i386/kernel/cpu/mtrr/main.c |6 --
arch/i386/kernel/microcode.c |8
arch/mips/kernel/mip
Currently i386 and x86_64 __cpu_up uses the services of the kevents
workqueue to bring the cpu up. Change this and use kthread workqueue
instead which is single_threaded and won't be frozen during
CPU_HOTPLUG.
Signed-off-by: Gautham R Shenoy <[EMAIL PROTECTED]>
Cc: Andi Kleen <[E
_cpu_up be avoided by some cleaner means.
Signed-off-by : Srivatsa Vaddagiri <[EMAIL PROTECTED]>
Signed-off-by : Gautham R Shenoy <[EMAIL PROTECTED]>
Signed-off-by : Rafael J. Wysocki <[EMAIL PROTECTED]>
--
include/linux/freezer.h | 10 --
include/linux/notifier.h
This patch adds provision to make the process freezer reentrant
for different kinds of freeze events.
Credit to Rafael Wysocki for the system_freeze_event_mask idea.
Signed-off-by: Gautham R Shenoy <[EMAIL PROTECTED]>
Cc: Pavel Machek <[EMAIL PROTECTED]>
Cc: Rafael J. Wysocki <[
based on the freeze events. Thus all
tasks which were previously marked PF_NOFREEZE are now
exempted from freezer using
freezer_exempt(FE_ALL);
which means exempt from all kinds of freezes.
Signed-off-by: Gautham R Shenoy <[EMAIL PROTECTED]>
Cc: Pavel Machek <[EMAIL PROTECTED]>
YMBOL(kthread_should_stop_check_freeze);
I would prefer to have try_to_freeze() followed by the
kthread_stop_info.k check. Something like
if (try_to_freeze())
/*some barrier ensuring all writes are completed */
if (kthread_stop_info.k == current)
return 1;
return 0;
This wou
;
> } while (!kthread_should_stop() && !fullstop);
> VERBOSE_PRINTK_STRING("rcu_torture_writer task stopping");
> while (!kthread_should_stop())
Paul,
Any reasons for not try_to_freeze()'ing the fakewriter and the reader
threads?? (Ok, I admit, I
*only* for hotplug.
Rafael, does that mean more status flags?!
Thanks and Regards
gautham.
--
Gautham R Shenoy
Linux Technology Center
IBM India.
"Freedom comes with a price tag of responsibility, which is still a bargain,
because Freedom is priceless!"
-
To unsubscribe from this list
_KILL_THREADS,
the notifications for which were being sent
*after* we thawed the processes in __cpu_down.
However, in the version which we are working on, we are thawing processes
individually in CPU_DEAD before cleaning/stopping them.
I haven't observed any bad lockups/freeze chills with this
glethreaded workqueue's for
hotplug, since we are not kthread_stopping them anywhere.
So this kthread_stop waiting for parent(khelper_wq) which is blocked on
wait_for_complete(child->vfork_done) shouldn't occur. No?
Thanks and Regards
gautham.
--
Gautham R Shenoy
Linux Techn
rozen context is a good thing to silence these warnings, but I guess that
would open up some new races.
>
> Greetings,
> Rafael
regards
gautham.
--
Gautham R Shenoy
Linux Technology Center
IBM India.
"Freedom comes with a price tag of responsibility, which is still a bargain,
beca
freezeable ??
thanks and regards
gautham
--
Gautham R Shenoy
Linux Technology Center
IBM India.
"Freedom comes with a price tag of responsibility, which is still a bargain,
because Freedom is priceless!"
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
cancel_work_sync();
>
> but it is ok to do cancel_work_sync() unconditionally.
True. But this might be a one off solution for slab. However, if someone
in the future might require to do a flush_workqueue from
CPU_DOWN_PREPARE context, we would need to find a new workaround.
So, I'
On Sat, Feb 17, 2007 at 11:02:33AM +0530, Gautham R Shenoy wrote:
> This looks ok, but probably we could do it in a better way.
> How about an api to thaw only a specific task something like
> thaw_process(struct task_struct p).
I see that thaw_process already exists in freezer.h! Awe
oes kthread_stop.
Rafael, does this have any negative impact on the freezer design?
> This should let us do kthread_stop() in CPU_DEAD itself (while processes
> are frozen)? That would allow us to do everything from CPU_DEAD itself
> (and not have CPU_DEAD_KILL_THREADS).
>
>
g warnings.
Let me know if this fix works for you or not.
regards
gautham.
Signed-off-by: Gautham R Shenoy <[EMAIL PROTECTED]>
kernel/cpu.c |2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
Index: linux-2.6.18/kernel/cpu.c
==
nts to be frozen for lets
say kprobes but not for cpu-hotplug. Cpu-hotplug and kprobes
may not have a dependency like the one that exists between cpu-hotplug
and suspend. So, at this moment, even I am not sure if there is a
need for the hierarchy.
>
> Rafael
Thanks and Regards
gau
401 - 500 of 525 matches
Mail list logo
