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'
> > > -
> > > 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
> +# 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
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 case.
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
> >
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
bove script 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??
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
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_
11 matches
Mail list logo
