From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S932995AbbJAKLZ (ORCPT <rfc822;w@1wt.eu>);
	Thu, 1 Oct 2015 06:11:25 -0400
Received: from www.linutronix.de ([62.245.132.108]:58523 "EHLO
	Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S932352AbbJAKK6 (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Thu, 1 Oct 2015 06:10:58 -0400
Date: Thu, 1 Oct 2015 12:10:03 +0200 (CEST)
From: Thomas Gleixner <tglx@linutronix.de>
To: Christoph Lameter <cl@linux.com>
cc: Andy Lutomirski <luto@amacapital.net>, Chris Metcalf <cmetcalf@ezchip.com>,
        Gilad Ben Yossef <giladb@ezchip.com>,
        Steven Rostedt <rostedt@goodmis.org>, Ingo Molnar <mingo@kernel.org>,
        Peter Zijlstra <peterz@infradead.org>,
        Andrew Morton <akpm@linux-foundation.org>,
        Rik van Riel <riel@redhat.com>, Tejun Heo <tj@kernel.org>,
        Frederic Weisbecker <fweisbec@gmail.com>,
        "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
        Viresh Kumar <viresh.kumar@linaro.org>,
        Catalin Marinas <catalin.marinas@arm.com>,
        Will Deacon <will.deacon@arm.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "H. Peter Anvin" <hpa@zytor.com>, X86 ML <x86@kernel.org>
Subject: Re: [PATCH v7 07/11] arch/x86: enable task isolation functionality
In-Reply-To: <alpine.DEB.2.20.1510010402040.8526@east.gentwo.org>
Message-ID: <alpine.DEB.2.11.1510011207400.4500@nanos>
References: <1443453446-7827-1-git-send-email-cmetcalf@ezchip.com> <1443453446-7827-8-git-send-email-cmetcalf@ezchip.com> <CALCETrWh2iW_sz7Bd+QqWa0OQZsrma_Dxk1zZEZUbpr9E+GuqA@mail.gmail.com> <5609B7C0.3010807@ezchip.com> <CALCETrVdZxkEeQd3=V6p_yLYL7T83Y3WfnhfVGi3GwTxF+vPQg@mail.gmail.com>
 <560ACD6F.7060102@ezchip.com> <CALCETrUaUOLpFqFbPcPRh=nf57XfpXU=QfMvD9YvQE8rSZikGg@mail.gmail.com> <alpine.DEB.2.11.1509302205030.4500@nanos> <560C4CF4.9090601@ezchip.com> <alpine.DEB.2.11.1509302358120.4500@nanos> <CALCETrX8oct5nQt=OCUc-1_wgZV1i27BO_rFnFDGaBWRYnWS4g@mail.gmail.com>
 <alpine.DEB.2.11.1510011008190.4500@nanos> <alpine.DEB.2.20.1510010402040.8526@east.gentwo.org>
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: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Thu, 1 Oct 2015, Christoph Lameter wrote:
> On Thu, 1 Oct 2015, Thomas Gleixner wrote:
> 
> > And I really want to see a proper engineering for that isolation
> > stuff, which can be done with an out of tree patch set in the first
> > place. But sure, it's more convenient to push crap into mainline and
> > let everyone else deal with the fallouts.
> 
> Yes lets keep the half baked stuff out please. Firing a timer that signals
> the app via a signal causes an event that is not unlike the OS noise that
> we are trying to avoid. Its an asynchrononous event that may interrupt at
> random locations in the code. In that case I would say its perfectly fine
> to use the tick and other timer processing on the processor that requested
> it. If you really want low latency and be OS intervention free then please
> do not set up timers. In fact any signal should bring on full OS services
> on a processor.
 
Right. That's a recommendation to the application developer, which he
can follow or not. And he has to deal with the consequences if not.

Thanks,

	tglx