On Sat, Feb 16, 2008 at 08:22:54PM +0300, Oleg Nesterov wrote:
This looks neat and clean.
Acked-by: Gautham R Shenoy <[EMAIL PROTECTED]>
> cpu_hotplug_begin() must be always called under cpu_add_remove_lock, this
> means
> that only one process can be cpu_hotplug.active_writ
don't you
> simply use smp_processor_id() right here ?
>
Agreed.
Also in patch 1, in cases where we're using markers in place of RCU_TRACE_ME(),
we need not pass the parameter and simply use smp_processor_id().
It's only the RCU_TRACE_RDP() that requires cpuid to be passed.
Thanks
get_cpu_var() safe in this context, since we've already
enabled the local interrupts and we're not in a preempt_disabled() ?
Thanks and Regards
gautham.
--
Gautham R Shenoy
Linux Technology Center
IBM India.
"Freedom comes with a price tag of responsibility, which is still a barg
pus() from the watchdog thread's context,
which is going to be kthread_stop'ed from a cpu-hotplug context.
This is what I think was happening in the case reported by Jiri.
Please find the patch below.
Thanks and Regards
gautham.
commit 15bfb662b35c609490185fba2fd4713d230b9374
Author: Gautham
ing
the check, then could we use the following patch
commit a49736844717e00f7a37c96368cea8fec7eb31cf
Author: Gautham R Shenoy <[EMAIL PROTECTED]>
Date: Mon Dec 10 15:43:32 2007 +0530
CPU-Hotplug: Add try_get_online_cpus()
Add the fastpath code, try_get_online_cpus() which will
return
On Mon, Dec 10, 2007 at 11:21:57AM +0100, Ingo Molnar wrote:
>
> * Gautham R Shenoy <[EMAIL PROTECTED]> wrote:
>
> > > i'm wondering, what's the proper CPU-hotplug safe sequence here
> > > then? I'm picking a CPU number from cpu_online_map, a
On Dec 10, 2007 4:58 PM, Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> * Gautham R Shenoy <[EMAIL PROTECTED]> wrote:
>
> > > say we've got 100 CPUs, so we've got 100 watchdog tasks running -
> > > one for each CPU. Checking for hung tasks is a g
disable-decoding-during-sizing-of-bars.patch.
>
> - git-sched was dropped due to breaking suspend-to-RAM.
Is it the same suspend-to-RAM problem that Jiri Slaby reported
here --> http://lkml.org/lkml/2007/12/7/125
The problem has been identified and a fix patch was provided.
Thanks an
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 body of a mess
cur while processing callbacks.
The discussion of the related theoretical race pointed out
by James Huang can be found here --> http://lkml.org/lkml/2007/11/20/603
Signed-off-by: Gautham R Shenoy <[EMAIL PROTECTED]>
Signed-off-by: Steven Rostedt <[EMAIL PROTECTED]>
Signed-off-by: Dipankar
ration for
subsequently merging the preemptible RCU implementation.
Signed-off-by: Gautham R Shenoy <[EMAIL PROTECTED]>
Signed-off-by: Dipankar Sarma <[EMAIL PROTECTED]>
Signed-off-by: Paul E. McKenney <[EMAIL PROTECTED]>
---
include/linux/rcuclassic.h | 161
off-by: Gautham R Shenoy <[EMAIL PROTECTED]>
Signed-off-by: Dipankar Sarma <[EMAIL PROTECTED]>
Signed-off-by: Paul E. McKenney <[EMAIL PROTECTED]>
---
kernel/rcuclassic.c |2 +-
kernel/rcupdate.c | 10 ++
2 files changed, 11 insertions(+), 1 deletions(-)
diff --git
can be switched to at compiler.
Also includes RCU tracing summarized in debugfs.
Signed-off-by: Gautham R Shenoy <[EMAIL PROTECTED]>
Signed-off-by: Dipankar Sarma <[EMAIL PROTECTED]>
Signed-off-by: Paul E. McKenney <[EMAIL PROTECTED]>
---
include/linux/rcuclassic.h
Preempt-RCU: CPU Hotplug handling
From: Paul E. McKenney <[EMAIL PROTECTED]>
This patch allows preemptible RCU to tolerate CPU-hotplug operations.
It accomplishes this by maintaining a local copy of a map of online
CPUs, which it accesses under its own lock.
Signed-off-by: Gautham R
quot;rcu" for the rcu_read_lock() API,
"rcu_sync" for rcu_read_lock() with synchronous reclamation,
@@ -82,8 +83,6 @@ be evident. ;-)
The entries are as follows:
-o "ggp": The number of counter flips (or batches) since boot.
-
o "rtc":
On Thu, Dec 13, 2007 at 09:42:53PM +0100, Ingo Molnar wrote:
>
> * Gautham R Shenoy <[EMAIL PROTECTED]> wrote:
>
> > Preempt-RCU: Update RCU Documentation.
> >
> > From: Paul E. McKenney <[EMAIL PROTECTED]>
> >
> > This patch updates the RCU d
Hi Steve,
On Thu, Dec 13, 2007 at 12:36:47PM -0500, Steven Rostedt wrote:
> On Thu, 13 Dec 2007, Gautham R Shenoy wrote:
>
> >
> > Currently it is based against the latest linux-2.6-sched-devel.git
> >
> > Awaiting your feedback!
>
> Hi Gautham,
>
>
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
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]
> >
> > > +
> > > +/*
&
void unregister_cpu_notifier(struct notifier_block *nb)
> {
> }
>
> +static inline void cpu_hotplug_init(void)
> +{
> +}
> +
> #endif /* CONFIG_SMP */
> extern struct sysdev_class cpu_sysdev_class;
> -extern void cpu_hotplug_init(void);
> extern void cpu_maps_u
From: Gautham R Shenoy <[EMAIL PROTECTED]>
Date: Thu, 15 Nov 2007 18:14:29 +0530
Subject: [PATCH 3/3] cpu-hotplug: Replace per-subsystem mutexes with
get_online_cpus()
This patch converts the known per-subsystem mutexes to get_online_cpus
put_online_cpus. It also eliminates the CPU_LOCK_A
From: Gautham R Shenoy <[EMAIL PROTECTED]>
Date: Thu, 15 Nov 2007 18:14:29 +0530
Subject: [PATCH 2/3] cpu-hotplug: Replace lock_cpu_hotplug() with
get_online_cpus()
Replace all lock_cpu_hotplug/unlock_cpu_hotplug from the kernel and use
get_online_cpus and put_online_cpus instead
From: Gautham R Shenoy <[EMAIL PROTECTED]>
Date: Thu, 15 Nov 2007 18:14:20 +0530
Subject: [PATCH 1/3] cpu-hotplug: Refcount based Cpu Hotplug implementation
This patch implements a Refcount + Waitqueue based model for
cpu-hotplug.
Now, a thread which wants to prevent cpu-hotplug, will bum
s 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 bo
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
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,
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:
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
> =
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
Hi Nathan,
> Gautham R Shenoy wrote:
> > On Thu, Oct 18, 2007 at 03:22:21AM -0500, Nathan Lynch wrote:
> > > Gautham R Shenoy wrote:
> > > > Hi Nathan,
> > > > > Hi Gautham-
> > > > >
> > > > > Gautham R Shenoy wrote:
named ?
Personally I would propose the following names to reflect the behaviour,
but if the community is okay with the word "lock" in the API's I don't
have any problems renaming them to what you've suggested.
/*
* Api's which ensure that the cpu_present_map and the cpu
On Sun, Oct 21, 2007 at 03:39:17PM +0400, Oleg Nesterov wrote:
> On 10/16, Gautham R Shenoy wrote:
> >
> > This patch converts the known per-subsystem cpu_hotplug mutexes to
> > get_online_cpus put_online_cpus.
> > It also eliminates the CPU_LOCK_ACQUIRE a
ainst 2.6.23-mm1 has behaved well
when it was stress tested with kernbench running while continuously
performing cpu-hotplug operations on i386, x86_64 and ppc64.
Awaiting your feedback.
Thanks and Regards
gautham.
--
Gautham R Shenoy
Linux Technology Center
IBM India.
"Freedom comes with a p
an ongoing cpu-hotplug operation are blocked
until the cpu-hotplug operation is over.
Signed-off-by: Gautham R Shenoy <[EMAIL PROTECTED]>
Signed-off-by: Paul Jackson <[EMAIL PROTECTED]> [For !CONFIG_HOTPLUG_CPU ]
---
include/linux/cpu.h |3 +
init/main.c |1
o any of the local data
structures. Hence the changes needs to be reviewed.
In case of pseries_add_processor/pseries_remove_processor, use
cpu_maps_update_begin()/cpu_maps_update_done() as we're modifying the
cpu_present_map there.
Signed-off-by: Gautham R Shenoy <[EMAIL PROTECTED]>
This patch converts the known per-subsystem mutexes to get_online_cpus
put_online_cpus. It also eliminates the CPU_LOCK_ACQUIRE
and CPU_LOCK_RELEASE hotplug notification events.
Signed-off-by: Gautham R Shenoy <[EMAIL PROTECTED]>
---
include/linux/notifier.h |4 +---
kernel
accesses to the
workqueues list.
Signed-off-by: Gautham R Shenoy <[EMAIL PROTECTED]>
---
kernel/workqueue.c | 49 ++---
1 file changed, 18 insertions(+), 31 deletions(-)
Index: linux-2.6.23/kernel/workq
Update the documentation for cpu hotplug to reflect the use
of newly added API's get_online_cpus()/put_online_cpus();
Signed-off-by: Gautham R Shenoy <[EMAIL PROTECTED]>
---
Documentation/cpu-hotplug.txt | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
Index: l
Hello Rusty,
On Wed, Oct 24, 2007 at 05:21:04PM +1000, Rusty Russell wrote:
> On Wednesday 24 October 2007 15:37:16 Gautham R Shenoy wrote:
> > @@ -712,7 +712,7 @@ static void start_workqueue_thread(struc
> >
> > if (p != NULL) {
> &g
On Wed, Oct 24, 2007 at 05:38:18PM +0400, Oleg Nesterov wrote:
> On 10/24, Gautham R Shenoy wrote:
> >
>
> (reordered)
>
> > With get_online_cpus()/put_online_cpus(), we can eliminate
> > the workqueue_mutex and reintroduce the workqueue_lock,
> > whic
On Wed, Oct 24, 2007 at 10:17:54PM +0400, Oleg Nesterov wrote:
> On 10/24, Gautham R Shenoy wrote:
> >
> > On Wed, Oct 24, 2007 at 10:04:41AM -0700, Christoph Lameter wrote:
> > > On Wed, 24 Oct 2007, Gautham R Shenoy wrote:
> > >
> > > > This is th
On Wed, Oct 24, 2007 at 10:04:41AM -0700, Christoph Lameter wrote:
> On Wed, 24 Oct 2007, Gautham R Shenoy wrote:
>
> > This is the version 2 of the refcount based cpu-hotplug "locking"
> > implementation.
>
> Uggh. This introduces a global lock that has t
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(+)
] 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
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
an ongoing cpu-hotplug operation are blocked
until the cpu-hotplug operation is over.
Signed-off-by: Gautham R Shenoy <[EMAIL PROTECTED]>
---
include/linux/cpu.h |2 +
init/main.c |1
kernel/cpu.c| 91
3 files c
Replace all lock_cpu_hotplug/unlock_cpu_hotplug from the kernel and use
get_online_cpus and put_online_cpus instead as it highlights
the refcount semantics in these operations.
Signed-off-by: Gautham R Shenoy <[EMAIL PROTECTED]>
---
arch/i386/kernel/cpu/mtrr/main.c
This patch converts the known per-subsystem cpu_hotplug mutexes to
get_online_cpus put_online_cpus.
It also eliminates the CPU_LOCK_ACQUIRE and CPU_LOCK_RELEASE hotplug
notification events.
Signed-off-by: Gautham R Shenoy <[EMAIL PROTECTED]>
---
include/linux/notifier.h |4 +---
the cpu goes offline. Since no one can queue any work
on an offlined cpu, this thread will be forever sleeping, untill
someone onlines the cpu.
Signed-off-by: Gautham R Shenoy <[EMAIL PROTECTED]>
---
kernel/workqueue.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
ood point! I'll add the comment before cpu_hotplug_begin().
>
> Linus
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!"
On Wed, Oct 17, 2007 at 10:47:41AM +1000, Rusty Russell wrote:
> On Tuesday 16 October 2007 20:34:17 Gautham R Shenoy wrote:
> > This patch implements a Refcount + Waitqueue based model for
> > cpu-hotplug.
>
> Hi Gautham,
Hi Rusty,
>
> I can't see where
Hi Paul,
On Wed, Oct 17, 2007 at 04:27:09AM -0700, Paul Jackson wrote:
> With the following patch, the four cpu hotplug patches by
> Gautham R Shenoy boot successfully on my sn2_defconfig ia64
> SN2 Altix system.
>
> This patch moves the cpu_hotplug_init() code outside
On Wed, Oct 17, 2007 at 04:29:12PM +1000, Rusty Russell wrote:
> On Wednesday 17 October 2007 15:37:54 Gautham R Shenoy wrote:
> > On Wed, Oct 17, 2007 at 10:47:41AM +1000, Rusty Russell wrote:
> > > On Tuesday 16 October 2007 20:34:17 Gautham R Shenoy wrote:
> > >
Hi Nathan,
> Hi Gautham-
>
> Gautham R Shenoy wrote:
> > Replace all lock_cpu_hotplug/unlock_cpu_hotplug from the kernel and use
> > get_online_cpus and put_online_cpus instead as it highlights
> > the refcount semantics in these operations.
>
> Something oth
On Thu, Oct 18, 2007 at 03:22:21AM -0500, Nathan Lynch wrote:
> Gautham R Shenoy wrote:
> > Hi Nathan,
> > > Hi Gautham-
> > >
> > > Gautham R Shenoy wrote:
> > > > Replace all lock_cpu_hotplug/unlock_cpu_hotplug from the kernel and use
> >
te
per_subsystem_cpus_mask before sending the
post_cpu_hotplug_notifications, the post_notification handlers
will be executing with the consistent value of the online_cpus mask.
Does anybody see a problem with this "update_now-cleanup_later"
approach ?
Thanks and Regards
gautham.
--
Gaut
On Fri, Dec 22, 2006 at 02:44:58AM -0800, Andrew Morton wrote:
> On Fri, 22 Dec 2006 16:07:24 +0530
> Gautham R Shenoy <[EMAIL PROTECTED]> wrote:
>
> > While we are at this per-subsystem cpuhotplug "locking", here's a
> > proposal that might put an end to
what Oleg
has posted. Will check that out tonite.
>
> should be scrapped. But really I forget what their status is. Gautham,
> can you please remind us where we're at?
>
If all goes fine (w.r.t cpufreq and workqueue), eliminating
lock_cpu_hotplug from kernel/*.c should be rel
On Wed, Jan 03, 2007 at 07:34:59PM +0530, Gautham R Shenoy wrote:
>
> > handle-cpu_lock_acquire-and-cpu_lock_release-in-workqueue_cpu_callback.patch
>
> Again, this one ensures that workqueue_mutex is taken/released on
> CPU_LOCK_ACQUIRE/CPU_LOCK_RELEASE events in the c
mutex in the cpu_hotplug callback function.
The same can be acheived by acquiring these mutexes in
CPU_UP_PREPARE/CPU_DOWN_PREPARE etc.
This is true for every subsystem that is cpu-hotplug aware.
> Oleg.
>
Thanks and Regards
gautham.
--
Gautham R Shenoy
Linux Technology Center
IBM India.
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'
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
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
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
_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
*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
been tested only on i386.
- Updated documentation for cpu-hotplug.
Any feedback would be greatly appreciated.
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 pricel
/CPU_UP_PREPARE in the
frozen context create any dirty dependencies in the future?
o Can the SYSTEM_RUNNING hack in _cpu_up be avoided by some cleaner means.
Signed-off-by : Srivatsa Vaddagiri <[EMAIL PROTECTED]>
Signed-off-by : Gautham R Shenoy <[EMAIL PROTECTED]>
--
include/linu
This patch reverts all the recent workqueue hacks added to make it
hotplug safe.
Signed-off-by : Srivatsa Vaddagiri <[EMAIL PROTECTED]>
Signed-off-by : Gautham R Shenoy <[EMAIL PROTECTED]>
kernel/workqueue.c | 225 +++--
1 files
This patch removes the per-subsystem hotcpu mutexes from sched and
slab subsystems.
Signed-off-by : Gautham R Shenoy <[EMAIL PROTECTED]>
--
kernel/sched.c | 16
mm/slab.c |6 --
2 files changed, 22 deletions(-)
Index: hotplug/kernel/s
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
On Wed, Feb 14, 2007 at 10:43:35PM +0100, Rafael J. Wysocki wrote:
> Hi,
>
> On Wednesday, 14 February 2007 15:40, Gautham R Shenoy wrote:
> > Hello Everybody,
> >
> > This is an experiment towards process_freezer based implementation
> > of cpu-hotplug. This i
re_hotplug_suspend();
primitive_cpu_down/_up();
perform_post_hotplug_suspend();
Does this look like a good thing to you?
> All in all, I think we should start from modifying the freezer and the
> classification of processes with respect to the freezing.
>
Cool! Lets get started then
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
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
==
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).
>
>
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
npopular lock_cpu_hotplug :-)
> p = __stop_machine_run(take_cpu_down, NULL, cpu);
> mutex_unlock(&cpu_bitmask_lock);
Looks good.
I'm wondering if we'll need to try_to_freeze in the fork and exit code
as well :?
Thanks and Regards
gautham.
--
Gautham R Sh
them.
Other than that, there are issues regarding the
workqueue-hotplug-"locking" which needs to be addressed,
probably in a seperate thread.
So could you please reconsider this decision to merge the
hotplug-locking rework, and let it stabilize in -mm for sometime ?
Thanks and Regards
gau
pu_hotplug callback path can cause a deadlock if we go for
per-subsystem hotcpu mutexes. Can you think of a way by which we can
avoid destroying the kondemand workqueue from the cpu-hotplug callback
path ? Please see http://lkml.org/lkml/2006/11/30/9 for the
culprit-callpath.
Thanks and Regards
g
U or
are of __init type.
Thus when CONFIG_HOTPLUG_CPU=y, all these cpu up functions would land up
in .text section, and when CONFIG_HOTPLUG_CPU=n, all these functions would
land up in .init section.
Tested on a i386 SMP machine running linux-2.6.20-rc3-mm1.
Signed-off-by: Gautham R Shenoy <[EMAIL
_rework patches)
So do we
- Rethink the strategy of per-subsystem hotcpu-locks ?
OR
- Think of a way to straighten out the super-convoluted cpufreq code ?
At the moment, I would suggest the latter :-)
Thanks and Regards
gautham.
--
Gautham R Shenoy
Linux Technology Center
IBM India.
"Fr
On Wed, Nov 29, 2006 at 01:05:56PM -0800, Andrew Morton wrote:
> On Wed, 29 Nov 2006 20:54:04 +0530
> Gautham R Shenoy <[EMAIL PROTECTED]> wrote:
>
> > Ok, so to cut the long story short,
> > - While changing governor from anything to
> > ondemand, locks
On Thu, Nov 30, 2006 at 09:58:07AM +0530, Gautham R Shenoy wrote:
>
> So can we ignore this circular-dep warning as a false positive?
> Or is there a way to exploit this circular dependency ?
>
> At the moment, I cannot think of way to exploit this circular dependency
> unle
On Thu, Nov 30, 2006 at 09:29:34AM +0100, Ingo Molnar wrote:
>
> * Gautham R Shenoy <[EMAIL PROTECTED]> wrote:
>
> > Ok, I see that we are already doing it :(. So we can end up in a
> > deadlock.
> >
> > Here's the culprit callpath:
>
> i
On Thu, Nov 30, 2006 at 09:31:44AM +0100, Ingo Molnar wrote:
>
> * Gautham R Shenoy <[EMAIL PROTECTED]> wrote:
>
> > So do we
> > - Rethink the strategy of per-subsystem hotcpu-locks ?
> >
> > OR
> >
> > - Think of a way to straighten out
On Thu, Nov 30, 2006 at 12:03:15PM +0100, Ingo Molnar wrote:
>
> * Gautham R Shenoy <[EMAIL PROTECTED]> wrote:
>
> > a) cpufreq maintain's it's own cpumask in the variable
> > policy->affected_cpus and says : If a frequency change is issued to
> >
On Thu, Nov 30, 2006 at 12:53:27PM +0100, Ingo Molnar wrote:
>
> * Gautham R Shenoy <[EMAIL PROTECTED]> wrote:
>
> > This is what is currently being done by cpufreq:
>
> ok!
>
> > a) get_some_cpu_hotplug_protection() [use either some global mechanism
> &
ck, i)) */
/* do some operation, which might sleep */
/* migrates to cpu j */
cpu_hotplug_unlock(); /* does mutex_unlock(&percpu(hotplug_lock, i)
while running on cpu j */
This would cause cacheline ping pong, no?
>
> Ingo
regards
gautham.
--
Gautham R Shenoy
Linux Technol
deadlock, since A acts as a mutex for B->C / C->B callpath.
Just curious :-) [ Well, I might encounter such a scenario in an attempt
to make cpufreq cpu-hotplug safe! ]
> Ingo
Thanks and Regards
gautham.
--
Gautham R Shenoy
Linux Technology Center
IBM India.
"
-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
goto bad;
> +if (!alien) {
> + kfree(shared);
> + kfree(nc);
> + goto bad;
> + }
> }
> cachep->
_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 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
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
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
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
; 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
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..
>
>
1 - 100 of 525 matches
Mail list logo
