From: Arjan van de Ven <arjan@linux.intel.com>
To: Mike Galbraith <efault@gmx.de>
Cc: RT <linux-rt-users@vger.kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
Steven Rostedt <rostedt@goodmis.org>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
Ingo Molnar <mingo@elte.hu>
Subject: Re: [patch] clockevents: Reinstate the per cpu tick skew
Date: Wed, 28 Dec 2011 14:32:06 +0100 [thread overview]
Message-ID: <4EFB1A56.1040902@linux.intel.com> (raw)
In-Reply-To: <1324977605.5217.132.camel@marge.simson.net>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 12/27/2011 10:20 AM, Mike Galbraith wrote:
>
> Quoting removal commit af5ab277ded04bd9bc6b048c5a2f0e7d70ef0867
> Historically, Linux has tried to make the regular timer tick on
> the various CPUs not happen at the same time, to avoid contention
> on xtime_lock.
>
> Nowadays, with the tickless kernel, this contention no longer
> happens since time keeping and updating are done differently. In
> addition, this skew is actually hurting power consumption in a
> measurable way on many-core systems. End quote
>
> Contention remains a problem if NO_HZ is either not configured, or
> is nohz=off disabled due to workload constraints. The RT kernel
> running nohz=off was measured to be using > 1.4% CPU just ticking
> 64 CPUs, with tick perturbation reaching ~80us. For loads where
> measured (>100us) NO_HZ latencies are intolerable, a must have.
I think we need to just say no to this, and kill the nohz=off option
entirely.
Seriously, are people still running with ticks for any legitimate
reasons? (and not just because they goofed their config file)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)
iQEcBAEBAgAGBQJO+xpVAAoJEEHdSxh4DVnEMvUH/A5qOO+igivDtdEjw5b39w3h
4fG7VLiyn34+AAFmBqfgx9dKbl4DkYzBBRYXcNVnicnjqnH7ZZ+FOvFo2zOCUiGG
xeDNox4hcl1jJ/6J1o6p1ecJXOUlbwNsXF9SVG38HPpJ4D0mgllAdy1wHJfv3+LA
Ad98sUDmhq2gpcjyupvv7exIor1i3JFo/Q+CFbDTVQrgz99zo/D2IX3ps4wRfhHq
q0rKcU4ZZJVHeHkItHOyEgeex9RPGlxNRSUu50zIHKugVlH9wbTtIzBkPzt1Nn0S
yThyQGd/xcFfQDaiwymWLf78d6wpEZ/BW+QIlPlO2xNMD/Qz980w86yyh0x2FQk=
=yDHd
-----END PGP SIGNATURE-----
next prev parent reply other threads:[~2011-12-28 13:32 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-24 9:06 3.0.14-rt31 + 64 cores = very bad jitter == highly synchronized tick? Mike Galbraith
2011-12-25 7:31 ` Mike Galbraith
2011-12-26 8:04 ` Mike Galbraith
2011-12-27 6:40 ` Mike Galbraith
2011-12-27 9:20 ` [patch] clockevents: Reinstate the per cpu tick skew Mike Galbraith
2011-12-28 5:17 ` Mike Galbraith
2011-12-28 8:22 ` Mike Galbraith
2011-12-28 9:59 ` Mike Galbraith
2011-12-28 13:35 ` Arjan van de Ven
2011-12-28 14:59 ` Mike Galbraith
2011-12-28 16:57 ` Peter Zijlstra
2011-12-28 17:28 ` Mike Galbraith
2011-12-29 7:22 ` Mike Galbraith
2011-12-28 13:32 ` Arjan van de Ven [this message]
2011-12-28 15:10 ` Mike Galbraith
2012-01-03 6:20 ` Mike Galbraith
2012-04-23 6:13 ` irq latency regression post af5ab277 - was " Mike Galbraith
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4EFB1A56.1040902@linux.intel.com \
--to=arjan@linux.intel.com \
--cc=a.p.zijlstra@chello.nl \
--cc=efault@gmx.de \
--cc=linux-rt-users@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.