linux-kernel - Re: [v7 0/8] Reduce cross CPU IPI interference

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]

Date:	Wed, 15 Feb 2012 17:19:11 +0200
From:	Gilad Ben-Yossef <gilad@...yossef.com>
To:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
Cc:	Chris Metcalf <cmetcalf@...era.com>,
	Frederic Weisbecker <fweisbec@...il.com>,
	linux-kernel@...r.kernel.org, Christoph Lameter <cl@...ux.com>,
	linux-mm@...ck.org, Pekka Enberg <penberg@...nel.org>,
	Matt Mackall <mpm@...enic.com>,
	Sasha Levin <levinsasha928@...il.com>,
	Rik van Riel <riel@...hat.com>,
	Andi Kleen <andi@...stfloor.org>, Mel Gorman <mel@....ul.ie>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Alexander Viro <viro@...iv.linux.org.uk>,
	Avi Kivity <avi@...hat.com>,
	Michal Nazarewicz <mina86@...a86.com>,
	Kosaki Motohiro <kosaki.motohiro@...il.com>,
	Milton Miller <miltonm@....com>
Subject: Re: [v7 0/8] Reduce cross CPU IPI interference

On Wed, Feb 15, 2012 at 5:11 PM, Peter Zijlstra <a.p.zijlstra@...llo.nl> wrote:
>
> On Fri, 2012-02-10 at 22:24 +0200, Gilad Ben-Yossef wrote:
> > I think the concept of giving the task some way to know if the tick is
> > disabled or not is nice.
> > Not sure the exact feature and surely not the interface are what we
> > should adopt - maybe
> > allow registering to receive a signal at the end of the tick when it
> > is disabled an re-enabled?
>
> Fair enough, I indeed missed that property. And yes that makes sense.
>
> It might be a tad tricky to implement as things currently stand, because
> AFAICR Frederic's stuff re-enables the tick on kernel entry (syscall)
> things like signal delivery or a blocking wait for it might be 'fun'.
>
> But I'll have to defer to Frederic, its been too long since I've seen
> his patches to remember most details.

Yes, what I had in mind is that since Frederic's patch set always
disables the tick
from inside the (last) timer tick, we can have the tick return to user
code from the timer
with a signal whenever it is disabled or re-enabled. Basically, have
the timer code make
the signal pending from inside the timer, so that the return to user
space on the special
timer ticks (the last before disable or the first after re-enable)
will be to a signal handler.

I don't know if what I wrote above actually makes sense or not :-)
I'll try to hack something
up and see.

Thanks,
Gilad

--
Gilad Ben-Yossef
Chief Coffee Drinker
gilad@...yossef.com
Israel Cell: +972-52-8260388
US Cell: +1-973-8260388
http://benyossef.com

"If you take a class in large-scale robotics, can you end up in a
situation where the homework eats your dog?"
 -- Jean-Baptiste Queru
--
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/