On 08/22/2016 11:37 AM, Paul E. McKenney wrote:
On Mon, Aug 22, 2016 at 11:12:45AM -0400, Mark Hounschell wrote:
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
wrote:
If latency is
On Mon, Aug 22, 2016 at 11:12:45AM -0400, Mark Hounschell wrote:
> 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
> >> wrote:
> >>>If latency is all you care about, one approach is
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
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 f
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
> 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
On Sun, Aug 21, 2016 at 10:53 PM, Paul E. McKenney
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_en
On Sun, Aug 21, 2016 at 07:26:04PM +0800, GeHao Kang wrote:
> On Fri, Aug 19, 2016 at 8:34 PM, Peter Zijlstra wrote:
>
> > Why are you wanting to use nohz_full if you do syscalls?
>
> We hope to reduce the overhead of the tick while the real time
> applications run,
> and these applications migh
On Fri, Aug 19, 2016 at 8:34 PM, Peter Zijlstra wrote:
> Why are you wanting to use nohz_full if you do syscalls?
We hope to reduce the overhead of the tick while the real time
applications run,
and these applications might do some syscalls to operate the I/O devices like
EtherCAT.
On Thu, Aug 18, 2016 at 11:25:00AM +0800, GeHao Kang wrote:
> Is the increased time fixed in each context switch? Because this increased
> time
> will be the latency of the real time application, we hope to confirm it.
> Thanks.
Why are you wanting to use nohz_full if you do syscalls?
Hi Chris,
Thanks for your reply.
Is the increased time fixed in each context switch? Because this increased time
will be the latency of the real time application, we hope to confirm it.
Thanks.
Regards,
- Kang
On Wed, Aug 17, 2016 at 8:18 PM, Chris Metcalf wrote:
> On 8/17/2016 2:26 AM, GeH
On 8/17/2016 2:26 AM, GeHao Kang wrote:
To investigate the cause, I use the kernel event tracer to find out
the events, user_enter and user_exit, of context_tracking would happen
on tickless isolated CPU. These two events means that this CPU enters
and exits the RCU extended quiescent state. Besi
Hi Frederic and Chris,
When the lmbench runs on the tickless isolated CPU, the context switch
latency on
this CPU is higher than the one on other CPU. The test platform is
Linux 4.4.12 with NO_HZ_FULL on I.MX6Q sabresd. The following is the
lmbench results about context switch:
lmbench runs on
11 matches
Mail list logo
