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 waitqueue_active() inside wakeup_readers() to determine if there are waiters. Right?
Ingo -------------------------------------> Subject: relay: fix timer madness From: Ingo Molnar <[email protected]> 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 <[email protected]> --- 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;
- 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.org/lkml/
- Follow-Ups:
- Re: [Question] Hooks for scheduler tracing (CFS)
- From: Mathieu Desnoyers <[email protected]>
- Re: [Question] Hooks for scheduler tracing (CFS)
- References:
- [Question] Hooks for scheduler tracing (CFS)
- From: "Remy Bohmer" <[email protected]>
- Re: [Question] Hooks for scheduler tracing (CFS)
- From: Arjan van de Ven <[email protected]>
- Re: [Question] Hooks for scheduler tracing (CFS)
- From: [email protected] (Ankita Garg)
- Re: [Question] Hooks for scheduler tracing (CFS)
- From: Ingo Molnar <[email protected]>
- Re: [Question] Hooks for scheduler tracing (CFS)
- From: [email protected] (Ankita Garg)
- Re: [Question] Hooks for scheduler tracing (CFS)
- From: Ingo Molnar <[email protected]>
- Re: [Question] Hooks for scheduler tracing (CFS)
- From: [email protected] (Ankita Garg)
- Re: [Question] Hooks for scheduler tracing (CFS)
- From: Ingo Molnar <[email protected]>
- Re: [Question] Hooks for scheduler tracing (CFS)
- From: Mathieu Desnoyers <[email protected]>
- [Question] Hooks for scheduler tracing (CFS)
- Prev by Date: Re: [GIT PATCH] ACPI patches for 2.6.23-rc1
- Next by Date: Re: [PATCH v2] Remove libsas PCI dependencies
- Previous by thread: Re: [Question] Hooks for scheduler tracing (CFS)
- Next by thread: Re: [Question] Hooks for scheduler tracing (CFS)
- Index(es):
 |