[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1329318679.2293.140.camel@twins>
Date: Wed, 15 Feb 2012 16:11:19 +0100
From: Peter Zijlstra <a.p.zijlstra@...llo.nl>
To: Gilad Ben-Yossef <gilad@...yossef.com>
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 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.
--
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