headers
office | 1 Jul 2008 01:34

Re: Dear friend

All Controlleds without Doctor Approval!

Phen...
Hydro..
Val...
Xan...
Ativ...
Ambi...

VISA, MasterCard, AMEX, DINERS, JCB, ECHECK... 

http://www.availmeds.com/ 

__________________________

cyplyat po oseni schitaut a potom strelyaut
sindrom kupirovannoy rekonstrukcii stydno za vcherashnee no ne pomnu pered kem

gibdd - goni inspektoru babki i duy dalshe

tyazhelo v uchenii - legko v grobu

ne tak strashen karlson kak ego krysha

shtirlicu vystrelili v  golovu razryvnaya -  raskinul mozgami shtirlic  

esli avtobusu izmenit zhena to on stanet trolleybusom

pravilnost nabora nomera opredelyaetsya po otvetu abonenta
(Continue reading)

Permalink | Reply | 0 comments |
headers
Emil Medve | 20 Jul 2008 17:46
Favicon

[PATCH] Export irq_set_affinity()

Signed-off-by: Emil Medve <Emilian.Medve <at> Freescale.com>
---

This is needed for drivers built as modules and running on SMP systems that want
to set initial/default explicit IRQ balancing

$ scripts/checkpatch.pl 0001-Export-irq_set_affinity.patch 
total: 0 errors, 0 warnings, 7 lines checked

0001-Export-irq_set_affinity.patch has no obvious style problems and is ready for submission.

 kernel/irq/manage.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c
index 77a51be..29c5b5a 100644
--- a/kernel/irq/manage.c
+++ b/kernel/irq/manage.c
 <at>  <at>  -96,6 +96,7  <at>  <at>  int irq_set_affinity(unsigned int irq, cpumask_t cpumask)
 #endif
 	return 0;
 }
+EXPORT_SYMBOL(irq_set_affinity);

 #ifndef CONFIG_AUTO_IRQ_AFFINITY
 /*
--

-- 
1.5.6.3

--
(Continue reading)

Permalink | Reply | 0 comments |
headers
Arjan van de Ven | 20 Jul 2008 18:16
Favicon

Re: [PATCH] Export irq_set_affinity()

On Sun, 20 Jul 2008 10:46:19 -0500
Emil Medve <Emilian.Medve <at> Freescale.com> wrote:

> Signed-off-by: Emil Medve <Emilian.Medve <at> Freescale.com>
> ---
> 
> This is needed for drivers built as modules and running on SMP
> systems that want to set initial/default explicit IRQ balancing

hi,

can you give an example of such a driver? It's custom to post such an
export patch as part of the patch that starts using the export...

Also... how much of this is already covered by the "don't balance" IRQ
flag already ?

--

-- 
If you want to reach me at my work email, use arjan <at> linux.intel.com
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org
--
To unsubscribe from this list: send the line "unsubscribe linux-smp" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Wolfgang Johann BETZ | 28 Jul 2008 10:26

RT task preemption/scheduling on SMP

Ciao,

while studying how real-time tasks (i.e. SCHED_FIFO or SCHED_RR) are
implemented on SMP systems with respect to preemption of lower priority
tasks, I came to the following question:
On uni-processor (UP) systems higher priority tasks are guaranteed to
preempt lower priority ones as soon as they become runnable. Now I am
wondering what happens on SMP systems as ideally for example once a RT
task which has a higher priority than any of the currently executing
tasks on the different CPUs becomes runnable it should also be
immediately scheduled on the CPU with the lowest priority currently
executing task. So, in terms of real-time, it should be guaranteed that
at any moment the set of runnable tasks with the highest priorities are
actually running on the available CPUs.
Now, while studying the Linux kernel (precisely version 2.6.24.4 with
Ingo Molnar's RT patch version 2.6.24.4-rt4 applied) it seemed to me as
if the kernel maintains a separate run queue for each of the available
CPUs and would anyway put a RT task which becomes (again) runnable on
the run queue of the CPU with the lowest priority currently executing
task, but I could not find anything which would make sure that a
rescheduling takes place (e.g. by triggering an IPI) in case the awaking
task has a higher priority and the current CPU is different from the
selected one (on whose run queue it has put the awaking task).
Now, first of all I would like to ask if my observation is correct?
If yes, I am wondering if this problem has in the meanwhile been tackled
with, is currently under investigation, is gonna be tackled with in the
(near) future, is considered as being non resolvable (e.g. without
compromising the overall throughput of the system too heavily), or ...
something else?
(Continue reading)

Permalink | Reply | 0 comments |

Gmane