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: <20150730194519.GA24607@lerouge>
Date:	Thu, 30 Jul 2015 21:45:22 +0200
From:	Frederic Weisbecker <fweisbec@...il.com>
To:	Chris Metcalf <cmetcalf@...hip.com>
Cc:	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 03:35:06PM -0400, Chris Metcalf wrote:
> On 07/29/2015 08:44 PM, Frederic Weisbecker wrote:
> >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.
> 
> True now, yes, I'm just looking ahead to doing better when we have
> a chance to improve things.

Sure, but we can fix that global IPI as well anyway.

> 
> >>You mentioned needing two fields, for task and for process, but in
> >>fact let's just add the one field to the one thing that needs it and
> >>not worry about additional possible future needs.  And note that it's
> >>the task_struct->signal where we need to add the field for posix cpu
> >>timers (the signal_struct) since that's where the sharing occurs, and
> >>given CLONE_SIGHAND I imagine it could be different from the general
> >>"process" model anyway.
> >Well, posix cpu timers can be install per process (signal struct) or
> >per thread (task struct).
> >
> >But we can certainly simplify that with a per process flag and expand
> >the thread dependency to the process scope.
> >
> >Still there is the issue of telling the CPUs where a process runs when
> >a posix timer is installed there. There is no process-like tsk->cpus_allowed.
> >Either we send an IPI everywhere like we do now or we iterate through all
> >threads in the process to OR all their cpumasks in order to send that IPI.
> 
> Is there a reason the actual timer can't run on a housekeeping
> core?  Then when it does wake_up_process() or whatever, the
> specific target task will get an IPI to wake up at that point.

It makes sense if people run posix cpu timers on nohz full CPUs. But nobody
reported such usecase yet.
--
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