[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150324191928.18b9f9f2@gandalf.local.home>
Date: Tue, 24 Mar 2015 19:19:28 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: "Suresh E. Warrier" <warrier@...ux.vnet.ibm.com>
Cc: linux-kernel@...r.kernel.org,
Frederic Weisbecker <fweisbec@...il.com>,
Ingo Molnar <mingo@...hat.com>,
Paul Mackerras <paulus@...ba.org>
Subject: Re: [PATCH] ring-buffer: More precise time stamps for nested writes
On Tue, 24 Mar 2015 18:10:05 -0500
> Although the ring buffer design is coded to avoid disabling
> interrupts, in this case there does not appear to be a practical way
> to solve this problem without disabling interrupts for a short time.
> To accommodate those architectures where disabling interrupts is
> expensive, we introduce a new kernel configuration option called
> CONFIG_RING_BUFFER_NESTED_WRITE_TIMESTAMP_UPDATE. On architectures
> where local_irq_save/restore is cheap, this should be set to Y,
> in order to get accurate timestamps. Other architectures can set it
> to N to avoid the overhead of local_irq_save/restore at the cost of
> getting inaccurate timestamps for nested writes.
There is no architecture where disabling interrupts is cheap. Actually,
enabling them is the killer. Doing function tracing shows the impact of
this rather well, as it would disable and enable interrupts for every
function call, which can get rather expensive in the sum of things, and
it does skew the timings and can make it more difficult to debug
heissenbugs.
That said, I feel your pain. I've had some ideas about doing this
without disabling interrupts. But for now, what can be done is to have
a flag that is set that will implement this or not. Using
static_branch() to implement it such that when its off it has no effect.
In the mean time, I can go and revisit trying to have better timings
with nested writes.
-- 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