* Frank Ch. Eigler ([EMAIL PROTECTED]) wrote:
> Hi -
>
> On Thu, Jul 26, 2007 at 11:02:26AM -0400, Mathieu Desnoyers wrote:
> > [...]
> > > > The problem is also in _stp_print_flush, not *only* in relay code:
> > > > void _stp_print_flush (void)
> > > > ...
> > > > spin_lock(&_stp_
* David J. Wilder ([EMAIL PROTECTED]) wrote:
>
> >I guess they might have to switch to such an asynchronous delivery
> >system if they want to do this properly. Simply put, your polling
> >solution is exactly what I do, but I check a flag set by the writer
> >instead of waking up the readers uncon
I guess they might have to switch to such an asynchronous delivery
system if they want to do this properly. Simply put, your polling
solution is exactly what I do, but I check a flag set by the writer
instead of waking up the readers unconditionally.
Mathieu
Ingo's solution could call wait
On Thu, Jul 26, 2007 at 12:22:31PM -0400, Frank Ch. Eigler wrote:
> Hi -
>
> On Thu, Jul 26, 2007 at 11:02:26AM -0400, Mathieu Desnoyers wrote:
> > [...]
> > > > The problem is also in _stp_print_flush, not *only* in relay code:
> > > > void _stp_print_flush (void)
> > > > ...
> > > >
Hi -
On Thu, Jul 26, 2007 at 11:02:26AM -0400, Mathieu Desnoyers wrote:
> [...]
> > > The problem is also in _stp_print_flush, not *only* in relay code:
> > > void _stp_print_flush (void)
> > > ...
> > > spin_lock(&_stp_print_lock);
> > > spin_unlock(&_stp_print_loc
Frank Ch. Eigler wrote:
Mathieu Desnoyers <[EMAIL PROTECTED]> writes:
[...]
The problem is also in _stp_print_flush, not *only* in relay code:
void _stp_print_flush (void)
...
spin_lock(&_stp_print_lock);
...
spin_unlock(&_stp_print_lock);
Tho
* Frank Ch. Eigler ([EMAIL PROTECTED]) wrote:
> Mathieu Desnoyers <[EMAIL PROTECTED]> writes:
>
> > [...]
> > The problem is also in _stp_print_flush, not *only* in relay code:
> > void _stp_print_flush (void)
> > ...
> > spin_lock(&_stp_print_lock);
> > ...
> >
Mathieu Desnoyers <[EMAIL PROTECTED]> writes:
> [...]
> The problem is also in _stp_print_flush, not *only* in relay code:
> void _stp_print_flush (void)
> ...
> spin_lock(&_stp_print_lock);
> ...
> spin_unlock(&_stp_print_lock);
>
> Those will turn
See below,
* Ankita Garg ([EMAIL PROTECTED]) wrote:
> Hi,
>
> On Mon, Jul 16, 2007 at 12:52:37PM -0700, Arjan van de Ven wrote:
> > On Mon, 2007-07-16 at 21:46 +0200, Remy Bohmer wrote:
> > > So I was wondering if anybody knows some tool/kernel mechanism which
> > > can do this?
> > > If not, I w
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))
> >
* Ingo Molnar ([EMAIL PROTECTED]) 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 = relay_switch_subbu
* 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 = relay_switch_subbuf(buf, length);
> memcpy(buf->data + buf->offse
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 th
* 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-generated
> > module, right? Maybe the problem is resolved b
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, C
* 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
>
> Call Trace:
> <#DB> [] __schedule_bug+0x4b/0x4f
> [] __sched_t
Hi,
On Mon, Jul 16, 2007 at 12:52:37PM -0700, Arjan van de Ven wrote:
> On Mon, 2007-07-16 at 21:46 +0200, Remy Bohmer wrote:
> > So I was wondering if anybody knows some tool/kernel mechanism which
> > can do this?
> > If not, I will build a kernel extension for it myself (new extension
> > to 'l
* Remy Bohmer <[EMAIL PROTECTED]> wrote:
> Hello Arjan,
>
> Thanks for this suggestion.
(please dont top-post, ever. See:
www.zipworld.com.au/~akpm/linux/patches/stuff/top-posting.txt)
> But I looked at Systemtap before, and as I remember, it is very
> flexible, but it only traces function c
Hello Arjan,
Thanks for this suggestion.
But I looked at Systemtap before, and as I remember, it is very
flexible, but it only traces function calls. (or am I missing
something?)
I also need this scheduler-tracer, besides for fully fledged X86
systems, also for ARM based boards also with a very m
* Remy Bohmer ([EMAIL PROTECTED]) wrote:
> Hello,
>
> I am looking for some tool/kernel machanism that enables me to track
> every schedule change on the CFS scheduler of the RT-kernel for some
> period of time.
> Thus a tool that gives me an overview after some time which task got
> "scheduled in
On Mon, 2007-07-16 at 21:46 +0200, Remy Bohmer wrote:
> So I was wondering if anybody knows some tool/kernel mechanism which
> can do this?
> If not, I will build a kernel extension for it myself (new extension
> to 'latency_trace' ?)
systemtap has been able to do such things for me in the past...
21 matches
Mail list logo
