[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140131145625.51128a8b@gandalf.local.home>
Date: Fri, 31 Jan 2014 14:56:25 -0500
From: Steven Rostedt <rostedt@...dmis.org>
To: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Cc: peterz@...radead.org, paulmck@...ux.vnet.ibm.com,
linux-rt-users@...r.kernel.org, linux-kernel@...r.kernel.org,
tglx@...utronix.de, Clark Williams <williams@...hat.com>
Subject: Re: [PATCH 2/2] timer: really raise softirq if there is irq_work to
do
On Fri, 31 Jan 2014 20:48:45 +0100
Sebastian Andrzej Siewior <bigeasy@...utronix.de> wrote:
> > As I have worked on code that uses irq_work() I can say that we want
> > the arch specific interrupts. For those architectures that don't have
> > it will experience larger latencies for the work required. It's
> > basically, a "too bad" for them.
>
> How "bad" is it? Is this something generic or just not getting
> perf events fast enough out? Most users don't seem to require small
> latencies.
I use it for waking up trace-cmd, and if it is too long, then it we can
miss lots of events. Same goes for perf.
Remember, irq_work can be triggered from NMI context. That means, if
the CPU is idle, it may be several seconds before that work happens.
That is WAY too long to wait.
Anyway, your suggestion to get rid of the arch code doesn't help. We
call the irq_work_run() from interrupt context whether there is work or
not, with or without removing the arch code. The only thing your
suggestion will do is to push the work from happening immediately to
happening on the timer tick (which may be several seconds later). I
don't see the savings.
-- Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists