On 08/22/2016 10:48 AM, Paul E. McKenney wrote:
On Mon, Aug 22, 2016 at 05:40:03PM +0800, GeHao Kang wrote:
On Sun, Aug 21, 2016 at 10:53 PM, Paul E. McKenney
<paulmck@xxxxxxxxxxxxxxxxxx> wrote:
If latency is all you care about, one approach is to map the device
registers into userspace and do the I/O without assistance from the
kernel.
In addition to the context switch latency, local interrupts are also
closed during
user_enter and user_exit of the context tracking. Therefore, the interrupt
latency might be also increased on the isolated tickless CPU. That
will degrade the
real time performance. Are these two events determined?
Hmmm... Why would you be taking interrupts on your isolated tickless
CPUs? Doesn't that defeat the purpose of designating them as isolated
and tickless?
Don't mean to butt in here but think about a "special" PCI card that
does nothing but take an external interrupt or external interrupts from
an outside source where the latency between the time it occurs on the
outside and the time an isolated processor can act on that event. The
IRQ of that card also being pinned/isolated to that processor. This is a
very common thing in the RT world.
Mark
The key point being that effective use of NO_HZ_FULL requires
careful configuration and complete understanding of your workload.
And it is quite possible that you instead need to use something
other than NO_HZ_FULL.
If your question is instead "why must interrupts be disabled during
context tracking", I must defer to people who understand the x86
entry/exit code paths better than I do.
Thanx, Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-api" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
