Comment 9 for bug 1285772

I think there are dual efforts in progress here. For ODP purposes, the
'full RT' kernel probably should not be required even if/when we get
NO_HZ_FULL/cpu isolation working there. However for those users who want
to work within the kernel stacks rather than from isolated cores, full RT
control of scheduling latencies may be a requirement. So we will have
efforts to optimize latencies on the RT kernel as well as providing support
for operation on isolated cores with minimal interference from the
kernel... RT or otherwise.

As per interrupt latency, that is mostly a function of the drivers selected
in a given install since the generic parts of the kernel already have
interrupts disabled for the briefest times possible... and interrupt
contexts operate independently of the scheduler itself. Where 'threaded
ISRs' are configured, interrupts not explicitly prevented from being
threaded will of course have most of their operation shifted into
schedulable contexts - but in cases where that induces unacceptable
latencies specific interrupts may be forced to remain unthreaded to
minimize any contention for CPU time.

On Mon, Mar 10, 2014 at 6:37 PM, Ola Liljedahl <email address hidden>wrote:

> No we don't know whether PREEMPT_RT is good enough (50-60 us interrupt
> latency under load on A15 according to Gary R. at LCA14) for the actual
> (base station) use cases considered by LNG (for NSN and Ericsson). Why?
> Because no actual requirements have been specified. Depending on the
> application design, multiple interrupt-based context switches per TTI with
> 60us latency might not be good enough, the interrupt handling and context
> switch overhead will also consume cycles that might be needed by the
> application. I had previously heard a requirement (or a wish) for interrupt
> latency in the 5-10us range (this also limits the overhead).
>
>
> On Tue, Mar 11, 2014 at 12:17 AM, Kim Phillips <<email address hidden>
> >wrote:
>
> > As I said, "getting the standard kernel good enough" is currently ==
> > patching it with PREEMPT_RT, at least for basestation users.
> >
> > --
> > You received this bug notification because you are a member of Linaro
> > Networking Group, which is subscribed to linaro-networking.
> > Matching subscriptions: LNG all
> > https://bugs.launchpad.net/bugs/1285772
> >
> > Title:
> > NO_HZ does not work for RT kernels
> >
> > Status in Linaro networking Group:
> > Confirmed
> >
> > Bug description:
> > https://validation.linaro.org/dashboard/image-charts/LNG-NO_HZ
> >
> > Although recent patches have fix NO_HZ for linux-lng and the
> > preemption build, the RT build fails with NO_HZ.
> >
> > This may be ok, if you have many cores running no_hz then you would
> > have less need for the cores running the kernel to have the best
> > possible latency ?
> >
> > To manage notifications about this bug go to:
> > https://bugs.launchpad.net/linaro-networking/+bug/1285772/+subscriptions
> >
>
> --
> You received this bug notification because you are subscribed to linaro-
> networking.
> Matching subscriptions: LNG all, lng-bugs
> https://bugs.launchpad.net/bugs/1285772
>
> Title:
> NO_HZ does not work for RT kernels
>
> Status in Linaro networking Group:
> Confirmed
>
> Bug description:
> https://validation.linaro.org/dashboard/image-charts/LNG-NO_HZ
>
> Although recent patches have fix NO_HZ for linux-lng and the
> preemption build, the RT build fails with NO_HZ.
>
> This may be ok, if you have many cores running no_hz then you would
> have less need for the cores running the kernel to have the best
> possible latency ?
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/linaro-networking/+bug/1285772/+subscriptions
>