from:"Max Krasnyanskiy"

Re: Tiny cpusets -- cpusets for small systems?

2008-02-25 Thread Max Krasnyanskiy


Paul Jackson wrote:

So. I see cpusets as a higher level API/mechanism and cpu_isolated_map as lower
level mechanism that actually makes kernel aware of what's isolated what's not.
Kind of like sched domain/cpuset relationship. ie cpusets affect sched domains
but scheduler does not use cpusets directly.


One could use cpusets to control the setting of cpu_isolated_map,
separate from the code such as your select_irq_affinity() that
uses it.
Yes. That's what I proposed too. In one of the CPU isolation threads with 
Peter. The only issue is that you need to simulate CPU_DOWN hotplug even in 
order to cleanup what's already running on those CPUs.



In a foreseeable future 2-8 cores will be most common configuration.
Do you think that cpusets are needed/useful for those machines ?
The reason I'm asking is because given the restrictions you mentioned
above it seems that you might as well just do
taskset -c 1,2,3 app1
	taskset -c 3,4,5 app2 


People tend to manage the CPU and memory placement of the threads
and processes within a single co-operating job using taskset
(sched_setaffinity) and numactl (mbind, set_mempolicy.)

They tend to manage the placement of multiple unrelated jobs onto
a single system, whether on separate or shared CPUs and nodes,
using cpusets.

>

Something like cpu_isolated_map looks to me like a system-wide
mechanism, which should, like sched_domains, be managed system-wide.
Managing it with a mechanism that encourages each thread to update
it directly, as if that thread owned the system, will break down,
resulting in conflicting updates, as multiple, insufficiently
co-operating threads issue conflicting settings.
I'm not sure how to interpret that. I think you might have mixed a couple of 
things I asked about in one reply ;-).
The question was that given the restrictions you talked about when you 
explained tiny-cpusets functionality I asked how much one gains from using 
them compared to the taskset/numactl. ie On the machines with 2-8 cores it's 
fairly easy to manage cpus with simple affinity masks.


The second part of your reply seems to imply that I somehow made you think 
that I suggested that cpu_isolated_map is managed per thread. That is of 
course not the case. It's definitely a system-wide mechanism and individual 
threads have nothing to do with it.
btw I just re-read my prev reply. I definitely did not say anything about 
threads managing cpu_isolated_map :).



Stuff that I'm working on this days (wireless basestations) is designed
with the  following model:
cpuN - runs soft-RT networking and management code
cpuN+1 to cpuN+x - are used as dedicated engines
ie Simplest example would be
cpu0 - runs IP, L2 and control plane
	cpu1 - runs hard-RT MAC 

So if CPU isolation is implemented on top of the cpusets what kind of API do 
you envision for such an app ?


That depends on what more API is needed.  Do we need to place
irqs better ... cpusets might not be a natural for that use.
Aren't irqs directed to specific CPUs, not to hierarchically
nested subsets of CPUs.


You clipped the part where I elaborated. Which was:
So if CPU isolation is implemented on top of the cpusets what kind of API do 
you envision for such an app ? I mean currently cpusets seems to be mostly dealing
with entire processes, whereas in this case we're really dealing with the threads. 
ie Different threads of the same process require different policies, some must run

on isolated cpus some must not. I guess one could write a thread's pid into 
cpusets
fs but that's not very convenient. pthread_set_affinity() is exactly what's 
needed.
In other words how would an app place its individual threads into the 
different cpusets.
IRQ stuff is separate, like we said above cpusets could simply update 
cpu_isolated_map which would take care of IRQs. I was talking specifically 
about the thread management.



Separate question:
  Is it desired that the dedicated CPUs cpuN+1 ... cpuN+x even appear
  as general purpose systems running a Linux kernel in your systems?
  These dedicated engines seem more like intelligent devices to me,
  such as disk controllers, which the kernel controls via device
  drivers, not by loading itself on them too.
We still want to be able to run normal threads on them. Which means IPI, 
memory management, etc is still needed. So yes they better show up as normal 
CPUs :)
Also with dynamic isolation you can for example un-isolate a cpu when you're 
compiling stuff on the machine and then isolate it when you're running special 
app(s).


Max
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH sched-devel 0/7] CPU isolation extensions

2008-02-25 Thread Max Krasnyanskiy

Hi Peter,

Sorry for delay in reply.

Please, wrap your emails at 78 - most mailers can do this.

Done.

On Fri, 2008-02-22 at 14:05 -0800, Max Krasnyanskiy wrote:

Peter Zijlstra wrote:

On Thu, 2008-02-21 at 18:38 -0800, Max Krasnyanskiy wrote:

List of commits
cpuisol: Make cpu isolation configrable and export isolated map

cpu_isolated_map was a bad hack when it was introduced, I feel we should

deprecate it and fully integrate the functionality into cpusets. That would
give a much more flexible end-result.

That's not not currently possible and will introduce a lot of complexity.
I'm pretty sure you missied the discussion I had with Paul (you were cc'ed on
that btw).
In fact I provided the link to that discussion in the original email.
Here it is again:
http://marc.info/?l=linux-kernel=120180692331461=2

I read it, I just firmly disagree.

Basically the problem is very simple. CPU isolation needs a simple/efficient way to check
if CPU N is isolated.

I'm not seeing the need for that outside of setting up the various
states. That is, once all the affinities are set up, you'd hardly ever
would (or should - imho) need to know if a particular CPU is isolated or not.
Unless I'm missing something that's only possible for a very static system.
What I mean is that yes you could go and set irq affinity, apps affinity,
workqueue thread affinity, etc not to run on the isolated cpus. It works
_until_ something changes, at which point the system needs to know that it's
not supposed to touch CPU N.
For example new IRQ is registered, new workqueue is created (fs mounted, net
network interface is created, etc), new kthread is started, etc.
Sure we can introduce default affinity masks for irqs, workqueues, etc. But
that's essentially just duplicating cpu_isolated_map.

cpuset/cgroup APIs are not designed for that. In other to figure
out if a CPU N is isolated one has to iterate through all cpusets and checks
their cpu maps.
That requires several levels of locking (cgroup and cpuset).

The other issue is that cpusets are a bit too dynamic (see the thread above for
more details)
we'd need notified mechanisms to notify subsystems when a CPUs become isolated.
Again more
complexity. Since I integrated cpu isolation with cpu hotplug it's already
addressed in a nice
simple way.

I guess you have another definition of nice than I do.

No, not really.
Lets talk specifics. My goal was not to introduce a bunch of new functionality
and rewrite workqueues and stuff, instead I wanted to integrated with existing
mechanisms. CPU maps are used everywhere and exporting cpu_isolated_map was a
natural way to make other parts of the kernel aware of the isolated CPUs.

Please take a look at that discussion. I do not think it's worth the effort to
put this into
cpusets. cpu_isolated_map is very clean and simple concept and integrates nicely with the
rest of the cpu maps. ie It's very much the same concept and API as cpu_online_map, etc.

I'm thinking cpu_isolated_map is a very dirty hack.

If we want to integrate this stuff with cpusets I think the best approach would be is to
have cpusets update the cpu_isolated_map just like it currently updates scheduler domains.

CPU-sets can already isolate cpus by either creating a cpu outside of any set,
or a set with a single cpu not shared by any other sets.
This only works for user-space. As I mentioned about for full CPU isolation various kernel
subsystems need to be aware of that CPUs are isolated in order to avoid activities on them.

Yes, hence the proposed system flag to handle the kernel bits like
unbounded kernel threads and IRQs.
I do not see a specific proposals here. The funny part that we're not even
disagreeing on the high level. Yes It'd be nice to have such a flag ;-)

But how will genirq subsystem, for example, be aware of that flag ?
ie How would it know that by default it is not supposed to route irqs to the
CPUs in the cpusets with that flag ?

As I explained above setting affinity for existing irqs is not enough.
Same for workqueus or any other susbsytem that wants to run per-cpu threads
and stuff.

This also allows for isolated groups, there are good reasons to isolate groups,
esp. now that we have a stronger RT balancer. SMP and hard RT are not
exclusive. A design that does not take that into account is too rigid.

You're thinking scheduling only. Paul had the same confusion ;-)

I'm not, I'm thinking it ought to allow for it.
One way I can think of how to support groups and allow for RT balancer is
this: Make scheduler ignore cpu_isolated_map and give cpusets full control of
the scheduler domains. Use cpu_isolated_map to only for hw irq and other
kernel sub-systems. That way cpusets could mark cpus in the group as isolated
to get rid of the kernel activity and build sched domain such that tasks get
balanced in it.
The thing I do not like about it is that there is no way to boot the system
with CPU N isolated

Re: [RFC] Genirq and CPU isolation

2008-02-25 Thread Max Krasnyanskiy


Randy Dunlap wrote:

On Fri, 22 Feb 2008 22:19:18 -0800 Max Krasnyansky wrote:

Hi Max,


diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c
index 438a014..e74db94 100644
--- a/kernel/irq/manage.c
+++ b/kernel/irq/manage.c
@@ -488,6 +491,26 @@ void free_irq(unsigned int irq, void *dev_id)
 }
 EXPORT_SYMBOL(free_irq);
 
+#ifndef CONFIG_AUTO_IRQ_AFFINITY

+/**
+ * Generic version of the affinity autoselector.
+ * Called under desc->lock from setup_irq().
+ * btw Should we rename this to select_irq_affinity() ?
+ */


Please don't begin comment blocks with "/**" unless they are in
kernel-doc format.  (See Documentation/kernel-doc-nano-HOWTO.txt
for details of it.)

My bad. Cut & pasted another function and forgot to nuke one asterisk.

Thanx for the review Randy.
Max
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC] Genirq and CPU isolation

2008-02-25 Thread Max Krasnyanskiy


Randy Dunlap wrote:

On Fri, 22 Feb 2008 22:19:18 -0800 Max Krasnyansky wrote:

Hi Max,


diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c
index 438a014..e74db94 100644
--- a/kernel/irq/manage.c
+++ b/kernel/irq/manage.c
@@ -488,6 +491,26 @@ void free_irq(unsigned int irq, void *dev_id)
 }
 EXPORT_SYMBOL(free_irq);
 
+#ifndef CONFIG_AUTO_IRQ_AFFINITY

+/**
+ * Generic version of the affinity autoselector.
+ * Called under desc-lock from setup_irq().
+ * btw Should we rename this to select_irq_affinity() ?
+ */


Please don't begin comment blocks with /** unless they are in
kernel-doc format.  (See Documentation/kernel-doc-nano-HOWTO.txt
for details of it.)

My bad. Cut  pasted another function and forgot to nuke one asterisk.

Thanx for the review Randy.
Max
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH sched-devel 0/7] CPU isolation extensions

2008-02-25 Thread Max Krasnyanskiy

Hi Peter,

Sorry for delay in reply.

Please, wrap your emails at 78 - most mailers can do this.

Done.

On Fri, 2008-02-22 at 14:05 -0800, Max Krasnyanskiy wrote:

Peter Zijlstra wrote:

On Thu, 2008-02-21 at 18:38 -0800, Max Krasnyanskiy wrote:

List of commits
cpuisol: Make cpu isolation configrable and export isolated map

cpu_isolated_map was a bad hack when it was introduced, I feel we should

deprecate it and fully integrate the functionality into cpusets. That would
give a much more flexible end-result.

I read it, I just firmly disagree.

Basically the problem is very simple. CPU isolation needs a simple/efficient way to check
if CPU N is isolated.

I guess you have another definition of nice than I do.

I'm thinking cpu_isolated_map is a very dirty hack.

If we want to integrate this stuff with cpusets I think the best approach would be is to
have cpusets update the cpu_isolated_map just like it currently updates scheduler domains.

But how will genirq subsystem, for example, be aware of that flag ?
ie How would it know that by default it is not supposed to route irqs to the
CPUs in the cpusets with that flag ?

As I explained above setting affinity for existing irqs is not enough.
Same for workqueus or any other susbsytem that wants to run per-cpu threads
and stuff.

You're thinking scheduling only. Paul had the same confusion ;-)

Re: Tiny cpusets -- cpusets for small systems?

2008-02-25 Thread Max Krasnyanskiy


Paul Jackson wrote:

So. I see cpusets as a higher level API/mechanism and cpu_isolated_map as lower
level mechanism that actually makes kernel aware of what's isolated what's not.
Kind of like sched domain/cpuset relationship. ie cpusets affect sched domains
but scheduler does not use cpusets directly.


One could use cpusets to control the setting of cpu_isolated_map,
separate from the code such as your select_irq_affinity() that
uses it.
Yes. That's what I proposed too. In one of the CPU isolation threads with 
Peter. The only issue is that you need to simulate CPU_DOWN hotplug even in 
order to cleanup what's already running on those CPUs.



In a foreseeable future 2-8 cores will be most common configuration.
Do you think that cpusets are needed/useful for those machines ?
The reason I'm asking is because given the restrictions you mentioned
above it seems that you might as well just do
taskset -c 1,2,3 app1
	taskset -c 3,4,5 app2 


People tend to manage the CPU and memory placement of the threads
and processes within a single co-operating job using taskset
(sched_setaffinity) and numactl (mbind, set_mempolicy.)

They tend to manage the placement of multiple unrelated jobs onto
a single system, whether on separate or shared CPUs and nodes,
using cpusets.



Something like cpu_isolated_map looks to me like a system-wide
mechanism, which should, like sched_domains, be managed system-wide.
Managing it with a mechanism that encourages each thread to update
it directly, as if that thread owned the system, will break down,
resulting in conflicting updates, as multiple, insufficiently
co-operating threads issue conflicting settings.
I'm not sure how to interpret that. I think you might have mixed a couple of 
things I asked about in one reply ;-).
The question was that given the restrictions you talked about when you 
explained tiny-cpusets functionality I asked how much one gains from using 
them compared to the taskset/numactl. ie On the machines with 2-8 cores it's 
fairly easy to manage cpus with simple affinity masks.


The second part of your reply seems to imply that I somehow made you think 
that I suggested that cpu_isolated_map is managed per thread. That is of 
course not the case. It's definitely a system-wide mechanism and individual 
threads have nothing to do with it.
btw I just re-read my prev reply. I definitely did not say anything about 
threads managing cpu_isolated_map :).



Stuff that I'm working on this days (wireless basestations) is designed
with the  following model:
cpuN - runs soft-RT networking and management code
cpuN+1 to cpuN+x - are used as dedicated engines
ie Simplest example would be
cpu0 - runs IP, L2 and control plane
	cpu1 - runs hard-RT MAC 

So if CPU isolation is implemented on top of the cpusets what kind of API do 
you envision for such an app ?


That depends on what more API is needed.  Do we need to place
irqs better ... cpusets might not be a natural for that use.
Aren't irqs directed to specific CPUs, not to hierarchically
nested subsets of CPUs.


You clipped the part where I elaborated. Which was:
So if CPU isolation is implemented on top of the cpusets what kind of API do 
you envision for such an app ? I mean currently cpusets seems to be mostly dealing
with entire processes, whereas in this case we're really dealing with the threads. 
ie Different threads of the same process require different policies, some must run

on isolated cpus some must not. I guess one could write a thread's pid into 
cpusets
fs but that's not very convenient. pthread_set_affinity() is exactly what's 
needed.
In other words how would an app place its individual threads into the 
different cpusets.
IRQ stuff is separate, like we said above cpusets could simply update 
cpu_isolated_map which would take care of IRQs. I was talking specifically 
about the thread management.



Separate question:
  Is it desired that the dedicated CPUs cpuN+1 ... cpuN+x even appear
  as general purpose systems running a Linux kernel in your systems?
  These dedicated engines seem more like intelligent devices to me,
  such as disk controllers, which the kernel controls via device
  drivers, not by loading itself on them too.
We still want to be able to run normal threads on them. Which means IPI, 
memory management, etc is still needed. So yes they better show up as normal 
CPUs :)
Also with dynamic isolation you can for example un-isolate a cpu when you're 
compiling stuff on the machine and then isolate it when you're running special 
app(s).


Max
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Module loading/unloading and "The Stop Machine"

2008-02-22 Thread Max Krasnyanskiy


Hi Andi,


Max Krasnyanskiy <[EMAIL PROTECTED]> writes:

static struct module *load_module(void __user *umod,
 unsigned long len,
 const char __user *uargs)
{
 ...

 /* Now sew it into the lists so we can get lockdep and oops
* info during argument parsing.  Noone should access us, since
* strong_try_module_get() will fail. */
   stop_machine_run(__link_module, mod, NR_CPUS);
 ...
}


Wow you found some really bad code. I bet it wouldn't be that
difficult to fix the code to allow oops safe list insertion
without using the big stop machine overkill hammer.

Let me know if you have something in mind. When I get a chance I'll stare
some more at that code and try to come up with an alternative solution.

Thanx
Max
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH sched-devel 0/7] CPU isolation extensions

2008-02-22 Thread Max Krasnyanskiy


Peter Zijlstra wrote:

On Fri, 2008-02-22 at 08:38 -0500, Mark Hounschell wrote:


List of commits
   cpuisol: Make cpu isolation configrable and export isolated map
 
cpu_isolated_map was a bad hack when it was introduced, I feel we should

deprecate it and fully integrate the functionality into cpusets. That would
give a much more flexible end-result.

CPU-sets can already isolate cpus by either creating a cpu outside of any set,
or a set with a single cpu not shared by any other sets.


Peter, what about when I am NOT using cpusets and are disabled in my config but
I still want to use this?


Then you enable it?

I'm with Mark on this one. For example if I have two core machine I do not need 
cpusets
to manage them.
Plus like I explained in prev email cpuset is higher level API. We can think of 
a way to
integrated them if needed.


   cpuisol: Do not schedule workqueues on the isolated CPUs
 
(per-cpu workqueues, the single ones are treated in the previous section)


I still strongly disagree with this approach. Workqueues are passive, they
don't do anything unless work is provided to them. By blindly not starting them
you handicap the system and services that rely on them.


Have things changed since since my first bad encounter with Workqueues.
I am referring to this thread. 

http://kerneltrap.org/mailarchive/linux-kernel/2007/5/29/97039 


Just means you get to fix those problems. By blindly not starting them
you introduce others.


Please give me an example of what you have in mind.
Also if you look at the patch (which I've now posted properly) it's not just 
not starting them.
I also redirected all future scheduled work to non-isolated CPU. ie If work is 
scheduled on the
isolated CPU this work is treated as if the work queue is single threaded. As I 
explained before
most subsystem do not care which CPU actually gets to execute the work. 
Oprofile is the only
one I know of that breaks because it cannot collect the stats from the isolated 
CPUs. I'm thinking
of a different solution for oprofile, maybe collection samples through IPIs or 
something.

Max
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH sched-devel 0/7] CPU isolation extensions

2008-02-22 Thread Max Krasnyanskiy


Mark Hounschell wrote:

Peter Zijlstra wrote:

On Thu, 2008-02-21 at 18:38 -0800, Max Krasnyanskiy wrote:

As you suggested I'm sending CPU isolation patches for review/inclusion into 
sched-devel tree. They are against 2.6.25-rc2.

You can also pull them from my GIT tree at
git://git.kernel.org/pub/scm/linux/kernel/git/maxk/cpuisol-2.6.git 
master
 
Post patches! I can't review a git tree..
 

Max, could you also post them for 2.6.24.2 stable please. Thanks

Will do.

Max
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH sched-devel 0/7] CPU isolation extensions

2008-02-22 Thread Max Krasnyanskiy

Peter Zijlstra wrote:

On Thu, 2008-02-21 at 18:38 -0800, Max Krasnyanskiy wrote:

As you suggested I'm sending CPU isolation patches for review/inclusion into
sched-devel tree. They are against 2.6.25-rc2.

You can also pull them from my GIT tree at
git://git.kernel.org/pub/scm/linux/kernel/git/maxk/cpuisol-2.6.git
master

Post patches! I can't review a git tree..

I did. But it looks like I screwed the --cc list. I just resent them.

List of commits
cpuisol: Make cpu isolation configrable and export isolated map

cpu_isolated_map was a bad hack when it was introduced, I feel we should

deprecate it and fully integrate the functionality into cpusets. That would
give a much more flexible end-result.

Basically the problem is very simple. CPU isolation needs a simple/efficient way to check
if CPU N is isolated. cpuset/cgroup APIs are not designed for that. In other to figure

out if a CPU N is isolated one has to iterate through all cpusets and checks
their cpu maps.
That requires several levels of locking (cgroup and cpuset).
The other issue is that cpusets are a bit too dynamic (see the thread above for
more details)
we'd need notified mechanisms to notify subsystems when a CPUs become isolated.
Again more
complexity. Since I integrated cpu isolation with cpu hotplug it's already
addressed in a nice
simple way.
Please take a look at that discussion. I do not think it's worth the effort to
put this into
cpusets. cpu_isolated_map is very clean and simple concept and integrates nicely with the
rest of the cpu maps. ie It's very much the same concept and API as cpu_online_map, etc.

If we want to integrate this stuff with cpusets I think the best approach would be is to
have cpusets update the cpu_isolated_map just like it currently updates scheduler domains.

You're thinking scheduling only. Paul had the same confusion ;-)
As I explained before I'm redefining (or proposing to redefine) CPU isolation to

1. Isolated CPU(s) must not be subject to scheduler load balancing
Users must explicitly bind threads in order to run on those CPU(s).

2. By default interrupts must not be routed to the isolated CPU(s)
User must route interrupts (if any) to those CPUs explicitly.

3. In general kernel subsystems must avoid activity on the isolated CPU(s) as
much as possible
Includes workqueues, per CPU threads, etc.
This feature is configurable and is disabled by default.

Only #1 has to do with the scheduling. The rest has _nothing_ to do with it.

cpuisol: Do not route IRQs to the CPUs isolated at boot

From the diffstat you're not touching the genirq stuff, but instead hack a

single architecture to support this feature. Sounds like an ill designed hack.

Ah, good point. This patches started before genirq was merged and I did not
realize
that there is a way to set default irq affinity with genirq.
I'll definitely take a look at that.

A better approach would be to add a flag to the cpuset infrastructure that says
whether its a system set or not. A system set would be one that services the
general purpose OS and would include things like the IRQ affinity and unbound
kernel threads (including unbound workqueues - or single workqueues). This flag
would default to on, and by switching it off for the root set, and a select
subset you would push the System away from those cpus, thereby isolating them.
You're talking about very high level API. I'm totally all for it. What the patches deal
with is actual low level stuff that is needed to do the "push the system away from those cpus".

As I mentioned above we can have cpuset update cpu_isolated_map for example.

cpuisol: Do not schedule workqueues on the isolated CPUs

(per-cpu workqueues, the single ones are treated in the previous section)

I still strongly disagree with this approach. Workqueues are passive, they
don't do anything unless work is provided to them. By blindly not starting them
you handicap the system and services that rely on them.

Oh boy, back to square one. I covered this already.
I even started a thread on that and explained what this is and why its needed.

Re: [PATCH sched-devel 0/7] CPU isolation extensions

2008-02-22 Thread Max Krasnyanskiy


Dmitry Adamushko wrote:

Hi Max,


 [ ... ]
 Last patch to the stop machine is potentially unsafe and is marked as 
experimental. Unfortunately
 it's currently the only option that allows dynamic module insertion/removal 
for above scenarios.


I'm puzzled by the following part (can be a misunderstanding from my side)

+config CPUISOL_STOPMACHINE
+   bool "Do not halt isolated CPUs with Stop Machine (EXPERIMENTAL)"
+   depends on CPUISOL && STOP_MACHINE && EXPERIMENTAL
+   help
+ If this option is enabled kernel will not halt isolated CPUs
+ when Stop Machine is triggered. Stop Machine is currently only
+ used by the module insertion and removal.

this "only" part. What about e.g. a 'cpu hotplug' case (_cpu_down())?
(or we should abstract it a bit to the point that e.g. a cpu can be
considered as 'a module'? :-)


My bad. I forgot to update that text. As you and other folks pointed out
stopmachine is used in a few other places besides module loading. We had 
a discussion about this awhile ago. I just forgot to update the text. 
Will do.


Max
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH sched-devel 0/7] CPU isolation extensions

2008-02-22 Thread Max Krasnyanskiy


Dmitry Adamushko wrote:

Hi Max,


 [ ... ]
 Last patch to the stop machine is potentially unsafe and is marked as 
experimental. Unfortunately
 it's currently the only option that allows dynamic module insertion/removal 
for above scenarios.


I'm puzzled by the following part (can be a misunderstanding from my side)

+config CPUISOL_STOPMACHINE
+   bool Do not halt isolated CPUs with Stop Machine (EXPERIMENTAL)
+   depends on CPUISOL  STOP_MACHINE  EXPERIMENTAL
+   help
+ If this option is enabled kernel will not halt isolated CPUs
+ when Stop Machine is triggered. Stop Machine is currently only
+ used by the module insertion and removal.

this only part. What about e.g. a 'cpu hotplug' case (_cpu_down())?
(or we should abstract it a bit to the point that e.g. a cpu can be
considered as 'a module'? :-)


My bad. I forgot to update that text. As you and other folks pointed out
stopmachine is used in a few other places besides module loading. We had 
a discussion about this awhile ago. I just forgot to update the text. 
Will do.


Max
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/