mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Ankita Garg <ankita@in.ibm.com>
Cc: Arjan van de Ven <arjan@infradead.org>,
	linux@bohmer.net, LKML <linux-kernel@vger.kernel.org>,
	RT-Users <linux-rt-users@vger.kernel.org>,
	mathieu.desnoyers@polymtl.ca
Subject: Re: [Question] Hooks for scheduler tracing (CFS)
Date: Thu, 26 Jul 2007 13:05:04 +0200	[thread overview]
Message-ID: <20070726110504.GB7673@elte.hu> (raw)
In-Reply-To: <20070726095948.GB19398@in.ibm.com>


* Ankita Garg <ankita@in.ibm.com> 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->offset, data, length);
>         buf->offset += length;
>         local_irq_restore(flags);

oh, what a fine piece of s^H^H :-/ Who in their right mind calls this 
from _tracing_ code:

                smp_mb();
                if (waitqueue_active(&buf->read_wait))
                        /*
                         * Calling wake_up_interruptible() from here
                         * will deadlock if we happen to be logging
                         * from the scheduler (trying to re-grab
                         * rq->lock), so defer it.
                         */
                        __mod_timer(&buf->timer, jiffies + 1);

and the comment is utter rubbish: __mod_timer() can lock up just as 
much. Just use an adaptive-polling method to drive the draining of the 
relay buffer, instead of mucking with timers from within the tracing 
code. Whoever implemented this has absolutely zero clue i have to say 
...

the smp_mb() is rubbish too.

could you try the patch below, does it fix the problem?

	Ingo

------------------------------------->
Subject: relay: fix timer madness
From: Ingo Molnar <mingo@elte.hu>

remove timer calls (!!!) from deep within the tracing infrastructure.
This was totally bogus code that can cause lockups and worse.
Poll the buffer every 2 jiffies for now.

Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
 kernel/relay.c |   14 +++++---------
 1 file changed, 5 insertions(+), 9 deletions(-)

Index: linux-rt-rebase.q/kernel/relay.c
===================================================================
--- linux-rt-rebase.q.orig/kernel/relay.c
+++ linux-rt-rebase.q/kernel/relay.c
@@ -319,6 +319,10 @@ static void wakeup_readers(unsigned long
 {
 	struct rchan_buf *buf = (struct rchan_buf *)data;
 	wake_up_interruptible(&buf->read_wait);
+	/*
+	 * Stupid polling for now:
+	 */
+	mod_timer(&buf->timer, jiffies + 1);
 }
 
 /**
@@ -336,6 +340,7 @@ static void __relay_reset(struct rchan_b
 		init_waitqueue_head(&buf->read_wait);
 		kref_init(&buf->kref);
 		setup_timer(&buf->timer, wakeup_readers, (unsigned long)buf);
+		mod_timer(&buf->timer, jiffies + 1);
 	} else
 		del_timer_sync(&buf->timer);
 
@@ -604,15 +609,6 @@ size_t relay_switch_subbuf(struct rchan_
 		buf->subbufs_produced++;
 		buf->dentry->d_inode->i_size += buf->chan->subbuf_size -
 			buf->padding[old_subbuf];
-		smp_mb();
-		if (waitqueue_active(&buf->read_wait))
-			/*
-			 * Calling wake_up_interruptible() from here
-			 * will deadlock if we happen to be logging
-			 * from the scheduler (trying to re-grab
-			 * rq->lock), so defer it.
-			 */
-			__mod_timer(&buf->timer, jiffies + 1);
 	}
 
 	old = buf->data;

  reply	other threads:[~2007-07-26 11:05 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-16 19:46 Remy Bohmer
2007-07-16 19:52 ` Arjan van de Ven
2007-07-16 20:17   ` Remy Bohmer
2007-07-16 21:12     ` Ingo Molnar
2007-07-26  7:28   ` Ankita Garg
2007-07-26  7:35     ` Ingo Molnar
2007-07-26  7:49       ` Ankita Garg
2007-07-26  7:53         ` Ingo Molnar
2007-07-26  9:59           ` Ankita Garg
2007-07-26 11:05             ` Ingo Molnar [this message]
2007-07-26 13:06               ` Mathieu Desnoyers
2007-07-26 17:45                 ` David J. Wilder
2007-07-26 18:30                   ` Mathieu Desnoyers
2007-07-26 13:20               ` Ankita Garg
2007-07-26 13:31     ` Mathieu Desnoyers
2007-07-26 14:47       ` Frank Ch. Eigler
2007-07-26 15:02         ` Mathieu Desnoyers
2007-07-26 16:22           ` Frank Ch. Eigler
2007-07-26 16:32             ` Ankita Garg
2007-07-26 18:25             ` Mathieu Desnoyers
2007-07-26 15:17         ` Arnaldo Carvalho de Melo
2007-07-16 20:07 ` Mathieu Desnoyers
2007-07-16 23:03 ` LTTng for 2.6.22.1-rt4 Mathieu Desnoyers
     [not found]   ` <3efb10970707170034t3e1dabe5wc70d41f6ab209c7e@mail.gmail.com>
2007-07-17 14:45     ` LTTng for 2.6.22.1-rt4 (timestamping) Mathieu Desnoyers
2007-07-17  7:23 ` [Question] Hooks for scheduler tracing (CFS) Sébastien Dugué

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20070726110504.GB7673@elte.hu \
    --to=mingo@elte.hu \
    --cc=ankita@in.ibm.com \
    --cc=arjan@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rt-users@vger.kernel.org \
    --cc=linux@bohmer.net \
    --cc=mathieu.desnoyers@polymtl.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®