lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150730144620.GA21890@lerouge>
Date:	Thu, 30 Jul 2015 16:46:22 +0200
From:	Frederic Weisbecker <fweisbec@...il.com>
To:	Luiz Capitulino <lcapitulino@...hat.com>
Cc:	Chris Metcalf <cmetcalf@...hip.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Preeti U Murthy <preeti@...ux.vnet.ibm.com>,
	Christoph Lameter <cl@...ux.com>,
	Ingo Molnar <mingo@...nel.org>,
	Viresh Kumar <viresh.kumar@...aro.org>,
	Rik van Riel <riel@...hat.com>
Subject: Re: [PATCH 08/10] posix-cpu-timers: Migrate to use new tick
 dependency mask model

On Thu, Jul 30, 2015 at 10:31:47AM -0400, Luiz Capitulino wrote:
> On Thu, 30 Jul 2015 02:44:45 +0200
> Frederic Weisbecker <fweisbec@...il.com> wrote:
> > On Wed, Jul 29, 2015 at 01:24:16PM -0400, Chris Metcalf wrote:
> > > I really worry about this!  The vision EZchip offers our customers is
> > > that they can run whatever they want on the slow path housekeeping
> > > cores, i.e. random control-plane code.  Then, on the fast-path cores,
> > > they run their nohz_full stuff without interruption.  Often they don't
> > > even know what the hell is running on their control plane cores - SNMP
> > > or random third-party crap or god knows what.  And there is a decent
> > > likelihood that some posix cpu timer code might sneak in.
> 
> I share this thinking. We do the exactly same thing for KVM-RT and I
> wouldn't be surprised at all if a posix timer pops up in the
> housekeeping CPUs.

Ok you guys convinced me, I'll reiterate with a per-process mask.

> 
> > I see. But note that installing a posix cpu timer ends up triggering an
> > IPI to all nohz full CPUs. That's how nohz full has always behaved.
> > So users running posix timers on nohz should already suffer issues anyway.
> 
> I haven't checked how this would affect us, but seems a lot less serious
> then not having nohz at all.

Indeed. It's the difference between just receiving one IPI on every CPU and
having one interrupt every 1/Hz.

I'll just keep that global IPI to tell all CPUs that they may run a task
with a posix cpu timer queued. It's necessary for the CPUs to restart the
tick if needed. It's the current behavior and it makes things very simple.
Besides, nobody complained about it yet.

I can fix it if people request it but this will be in another patchset because
it's a complicated issue on its own.

To summarize: this patchset won't change the current upstream behaviour.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ