From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932831AbbI3U07 (ORCPT ); Wed, 30 Sep 2015 16:26:59 -0400 Received: from www.linutronix.de ([62.245.132.108]:44443 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932502AbbI3U04 (ORCPT ); Wed, 30 Sep 2015 16:26:56 -0400 Date: Wed, 30 Sep 2015 22:25:59 +0200 (CEST) From: Thomas Gleixner To: Andy Lutomirski cc: Chris Metcalf , Gilad Ben Yossef , Steven Rostedt , Ingo Molnar , Peter Zijlstra , Andrew Morton , Rik van Riel , Tejun Heo , Frederic Weisbecker , "Paul E. McKenney" , Christoph Lameter , Viresh Kumar , Catalin Marinas , Will Deacon , "linux-kernel@vger.kernel.org" , "H. Peter Anvin" , X86 ML Subject: Re: [PATCH v7 07/11] arch/x86: enable task isolation functionality In-Reply-To: Message-ID: References: <1443453446-7827-1-git-send-email-cmetcalf@ezchip.com> <1443453446-7827-8-git-send-email-cmetcalf@ezchip.com> <5609B7C0.3010807@ezchip.com> <560ACD6F.7060102@ezchip.com> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 29 Sep 2015, Andy Lutomirski wrote: > On Tue, Sep 29, 2015 at 10:42 AM, Chris Metcalf wrote: > > Scheduling a timer for 10 minutes away is typically done by > > scheduling timers for the max timer granularity (which could > > be just a few seconds) and then waking up a couple of hundred > > times between now and now+10 minutes. Doing this breaks > > the task isolation guarantee, so we can't return to userspace > > while something like that is pending. You'd have to do it > > by polling in userspace to avoid the unexpected interrupts. > > > > Really? That sucks. Hopefully we can fix it. Well. If there is a timer pending, then what do you want to fix? If the hardware does not allow to program a long out expiry time, then the kernel cannot do anything about it. That depends on the timer hardware, really. PIT can do ~50ms, HPET ~3min, APIC timer ~32sec, TSC deadline timer ~500years. > > I suppose if your hardware supported it, you could imagine > > a mode where userspace can request an alarm a specific > > amount of time in the future, and the task isolation code > > would then ignore an alarm that was going off at that > > specific time. Ignore in what way? > > But I'm not sure what hardware does support > > that (I know tile uses the "few seconds and re-arm" model), > > and it seems like a pretty corner use-case. We could > > certainly investigate adding such support later, but I don't see > > it as part of the core value proposition for task isolation. I'm really not following here. If user space requested that timer, WHY on earth do you want to spin in the kernel until it fired? That's insane. > Intel chips Sandy Bridge and newer certainly support this. Other chips > might support it as well. Whether the kernel is able to program the > TSC deadline timer like that is a different question. If the next expiry is out 100 years then we will happily program it for that expiry time. Thanks, tglx