[sles-beta] SLES 12 SP1 BETA3 - tickless kernel

Laxman, Mahendra mahendral at millenniumit.com
Tue Oct 20 19:17:36 MDT 2015


Libor,

Sorry about the late reply. Thank for the explanation. I also observed there is reasonable slow down in syscalls by enabling CONFIG_NO_HZ_FULL. Further our baseline tests shown better latency numbers on SLES12  compared to RHEL7 even though sysjitter shown the opposite.

Also I would like to have a look on SLERT 12 SP1 as well.

Thanks and Regards,
Mahendra. 
________________________________________
From: Libor Pechacek [lpechacek at suse.com]
Sent: 25 September 2015 20:27
To: Laxman, MahendraSLERT 12 SP1
Cc: sles-beta at lists.suse.com
Subject: Re: [sles-beta] SLES 12 SP1 BETA3 - tickless kernel

Mahendra,

The main reason for not enabling CONFIG_NO_HZ_FULL in SLES 12 SP1 by default is
immaturity of the code in v3.12.  There are 360 additional patches needed towhen
get RCU, timers, workqueues and other key subsystems behave well in adaptive
tick mode.  Such a large backport was out of scope for the service pack.

Ad power saving, adaptive tick mode triggers for CPUs which have only one task
to run.  Chances are the task bound to the CPU is running (otherwise wewhen
wouldn't be interested in uninterrupted execution, would we?) hence periodic
timer interrupt will not increase current drawn by the CPU.

Last but not least, the feature is not for free.  Increased code complexity
causes ~0.5% syscall slow down with nohz_full=off.  This performance penalty
increases to 100% when nohz_full is enabled.  This is also something whenwe will
take into account when enabling this feature in stock SLES kernel.

Hope this provides necessary context.

Regards,
                Libor Pechacek

On Fri 25-09-15 10:50:23, Laxman, Mahendra wrote:
> Hi Libor,when
>
> It is great to here about that..
>
> CONFIG_NO_HZ_FULL=y will also enhance power-saving as well.
> I think it will be beneficial to have it in generic kernel as well.
> Is there any reason that we can't have this in generic kernel?
>
> BTW RHEL generic kernel already having this enabled.
>
> Regards,
> Mahendra.
> ________________________________________
> From: Libor Pechacek [lpechacek at suse.com]
> Sent: 25 September 2015 15:20
> To: Laxman, Mahendra
> Cc: sles-beta at lists.suse.com
> Subject: Re: [sles-beta]  SLES 12 SP1 BETA3 - tickless kernel
>
> Hello Mahendra,
>
> A kernel with CONFIG_NO_HZ_FULL=y enabled is part of the upcoming SLERT 12 SP1.
> Lab test results with sysjitter and the latest SLERT development snapshot
> show equally good results as your ones.
>
> Regards,better
>                 Libor Pechacek
>better
> On Fri 25-09-15 06:22:13, Laxman, Mahendra wrote:
> > Hi all,
> >
> > I would like to have tickless mode enable in SLES12 SP1 kernel to reduce the
> > system jitter produced by the clock interrupts.
> > I did test this behavior on the kernel version 3.12.47-2-default and it
> > reduced a significant amount of jitter.
> > The jitter was measured using sysjitter-1.3
> > [http://www.openonload.org/download.html] with command './sysjitter --runtime
> > 20 300'.
> > Only the last line of the test result is given below which represent the
> > percentage jitter caused  through 20s test duration and the lower values are
> > better.
> >
> > without tickless mode (default Kernel with boot parameters:  isolcpus=1-15 )
> > core_i: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
> > int_total(%): 0.152 0.113 0.113 0.113 0.116 0.115 0.113 0.116 0.140 0.120 0.122 0.119 0.120 0.122 0.119 0.119
> >
> > with tickless mode (Kernel compiled with CONFIG_NO_HZ_FULL=y  and boot parameters: nohz_full=1-15 isolcpus=1-15 rcu_nocbs=1-15)
> > core_i: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
> > int_total(%): 0.365 0.015 0.017 0.015 0.019 0.015 0.015 0.019 0.004 0.004 0.004 0.004 0.003 0.004 0.004 0.004
> >
> > Full test output is also attached herewith.
> >
> >
> > What is the possibility of having tickless mode enabled?
> >
> >
> > Thanks & Regards,
> > Mahendra.
>
>
> --
> Libor Pechacek
> SUSE Labs
>
>
> This e-mail transmission (inclusive of any attachments) is strictly confidential and intended solely for the ordinary user of the e-mail address to which it was addressed. It may contain legally privileged and/or CONFIDENTIAL information. The unauthorized use, disclosure, distribution printing and/or copying of this e-mail or any information it contains is prohibited and could, in certain circumstances, constitute an offence. If you have received this e-mail in error or are not an intended recipient please inform the sender of the email and MillenniumIT immediately by return e-mail or telephone (+94-11) 2416000. We advise that in keeping with good computing practice, the recipient of this e-mail should ensure that it is virus free. We do not accept responsibility for any virus that may be transferred by way of this e-mail. E-mail may be susceptible to data corruption, interception and unauthorized amendment, and we do not accept liability for any such corruption, interception
>   or amendment or any consequences thereof.  www.millenniumit.com
>
>
> _______________________________________________
> sles-beta mailing list
> sles-beta at lists.suse.com
> http://lists.suse.com/mailman/listinfo/sles-beta

--
Libor Pechacek
SUSE Labs


More information about the sles-beta mailing list