; 2) run on CPU task previously ran on
>
> I think #1 may result in lower latency. But, if the task has lots of
> cache warmth the lower wakeup latency may be negated by running on a
> 'remote' cpu.
Could we use task_hot() routine to find if the task is cache hot? If it
isn't, if possible
on a
'remote' cpu.
Could we use task_hot() routine to find if the task is cache hot? If it
isn't, if possible, we could run on current CPU, else, if possible, on
the CPU it last ran on?
--
Regards,
Ankita Garg ([EMAIL PROTECTED])
Linux Technology Center
IBM India Systems Technology Labs
> > > -
> > > 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.o
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/
>
--
Regards,
Ankita Garg ([EMAIL PROTECTE
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/
--
Regards,
Ankita Garg ([EMAIL PROTECTED])
Linux Technology Center
IBM India Systems Technology Labs,
Bangalore, India
-
To unsubscribe from
PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
Regards,
Ankita Garg ([EMAIL PROTECTED])
Linux Technology Center
IBM India Systems Technology Labs,
Bangalore, India
-
To unsubscribe from this list: send the line
> +# define _write_trylock_irqsave(rwl, flags) \
> + rt_write_trylock_irqsave(rwl, flags)
>
> # define _read_lock(rwl) rt_read_lock(rwl)
> # define _write_lock(rwl)rt_write_lock(rwl)
>
--
Regards,
Ankita Garg ([EMAIL PROTECTED])
Linux Technology Center
IBM India Systems &a
)
-#define _write_trylock_irqsave(rwl, flags) rt_write_trylock_irqsave(rwl,
flags)
+# define _write_trylock_irqsave(rwl, flags) \
+ rt_write_trylock_irqsave(rwl, flags)
# define _read_lock(rwl) rt_read_lock(rwl)
# define _write_lock(rwl)rt_write_lock(rwl)
--
Regards,
Ankita Garg
cally disable hardware interrupts.
>
> > You just don't want to sleep in the tracing code. [...] Since you
> > will likely disable preemption, make sure your tracing code executes
> > in a deterministic time.
>
> Definitely, that has always been the ca
Hi Ingo,
On Thu, Jul 26, 2007 at 01:05:04PM +0200, Ingo Molnar wrote:
>
> * Ankita Garg <[EMAIL PROTECTED]> wrote:
>
> > local_irq_save(flags);
> > buf = _stp_chan->buf[smp_processor_id()];
> > if (unlikely(buf->o
On Thu, Jul 26, 2007 at 09:53:53AM +0200, Ingo Molnar wrote:
>
> * Ankita Garg <[EMAIL PROTECTED]> wrote:
>
> > > I'd suggest to not put a probe into a preempt-off section - put it
> > > to the beginning and to the end of schedule() to capture
> &g
On Thu, Jul 26, 2007 at 09:35:20AM +0200, Ingo Molnar wrote:
>
> * Ankita Garg <[EMAIL PROTECTED]> wrote:
>
> > The probe point did get triggered, and soon after that I had the
> > following in dmesg, leading to system hang...
> >
> > BUG: scheduling wh
t is just one of the many probe points that I
tried. In all cases, printing data from within the probe point resulted in the
hang (as when I do the printing at the time the script is stopped,
everything works just fine!).
Any idea why this could be happening? An -rt issue or systemtap bug??
--
Reg
On Thu, Jul 26, 2007 at 09:35:20AM +0200, Ingo Molnar wrote:
* Ankita Garg [EMAIL PROTECTED] wrote:
The probe point did get triggered, and soon after that I had the
following in dmesg, leading to system hang...
BUG: scheduling while atomic: softirq-rcu/3/0x0004/52, CPU#3
do the printing at the time the script is stopped,
everything works just fine!).
Any idea why this could be happening? An -rt issue or systemtap bug??
--
Regards,
Ankita Garg ([EMAIL PROTECTED])
Linux Technology Center
IBM India Systems Technology Labs,
Bangalore, India
-
To unsubscribe
Hi Ingo,
On Thu, Jul 26, 2007 at 01:05:04PM +0200, Ingo Molnar wrote:
* Ankita Garg [EMAIL PROTECTED] wrote:
local_irq_save(flags);
buf = _stp_chan-buf[smp_processor_id()];
if (unlikely(buf-offset + length _stp_chan-subbuf_size))
length
On Thu, Jul 26, 2007 at 09:53:53AM +0200, Ingo Molnar wrote:
* Ankita Garg [EMAIL PROTECTED] wrote:
I'd suggest to not put a probe into a preempt-off section - put it
to the beginning and to the end of schedule() to capture
context-switches. _stp_print_flush() is in the systemtap
[...]
We will review that part of the related code.
- FChE
--
Regards,
Ankita Garg ([EMAIL PROTECTED])
Linux Technology Center
IBM India Systems Technology Labs,
Bangalore, India
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL
tch to fix BUG in drain_array()
Signed-off-by: Ankita Garg
--
slab.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
Index: linux-2.6.20-rt8/mm/slab.c
===
--- linux-2.6.20-rt8.orig/mm/slab.c 2007-04-18 18:41:22.0 +0
()
Signed-off-by: Ankita Garg ankita2in.ibm.com
--
slab.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
Index: linux-2.6.20-rt8/mm/slab.c
===
--- linux-2.6.20-rt8.orig/mm/slab.c 2007-04-18 18:41:22.0 +0530
+++ linux
Looking at oom_kill.c, found that the intention to not kill the selected
process if any of its children/siblings has OOM_DISABLE set, is not being met.
Signed-off-by: Ankita Garg <[EMAIL PROTECTED]>
Index: ankita/linux-2.6.20.1/mm/oom_
Looking at oom_kill.c, found that the intention to not kill the selected
process if any of its children/siblings has OOM_DISABLE set, is not being met.
Signed-off-by: Ankita Garg [EMAIL PROTECTED]
Index: ankita/linux-2.6.20.1/mm/oom_kill.c
22 matches
Mail list logo
