From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932938AbbI3U6y (ORCPT ); Wed, 30 Sep 2015 16:58:54 -0400 Received: from mail-db3on0090.outbound.protection.outlook.com ([157.55.234.90]:35488 "EHLO emea01-db3-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S932774AbbI3U6t (ORCPT ); Wed, 30 Sep 2015 16:58:49 -0400 Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=cmetcalf@ezchip.com; Subject: Re: [PATCH v7 07/11] arch/x86: enable task isolation functionality To: Thomas Gleixner , Andy Lutomirski 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> CC: 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 From: Chris Metcalf Message-ID: <560C4CF4.9090601@ezchip.com> Date: Wed, 30 Sep 2015 16:58:28 -0400 User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [12.216.194.146] X-ClientProxiedBy: CY1PR21CA0120.namprd21.prod.outlook.com (25.164.213.46) To DB5PR02MB0775.eurprd02.prod.outlook.com (25.161.243.146) X-Microsoft-Exchange-Diagnostics: 1;DB5PR02MB0775;2:C5YqzaapSbPE+TpLk3Br/FCz3z/+ySdSeO+kmqhY9UfZQJxP5qDUO+tpda7aBpSIWaBxse3sWi+8Jjvne9JF/Dijw4IJyqK1TlcxDJcij6vPfL3NxPrGB4YN1jNaflLpYx+TU/1w7WqLWIS6aBGyzACnhLnrZ2yZXYS7xr1v/Y0=;3:3QKs4S0Fd9MML2hOVN4gQI76pDMdHXxoYtxkNUP21uYX8u9JspSvO7aP559ZVGV+AaTUQv5Hx0f+m0OxUyoEFdAn8xNlcEWxBWw5SoCzX2am6A8O6Ku/roquTk7uxz4qo2Fihwc9UpOH4RhQrweOkQ==;25:LAPwmzNTe7wa/1akpNnrzQHAlaKFTsbVHGsxf7t6qVUCjiNhasYxzEFwbtxcj/ZT9GuSAcmWOjyVsFYrOAl/aZ5SDRoSrNyDPCrB2MoRnzCCGrhVksaud0MaYC6DZsrd2oGWsLJ/aGHysyHdmgLaE+n/N7Tk0G/mb0yN6+0MLq1jDqwMnA/HcIniYgeWGgv/sfrfV3DLNrHNVxx7hk9SSkeaHF4NCZiCpUlELEKXe/+P4ywT4G3JjiHGvrErPf8sDn89lrbnSJetoxwThASSig==;20:v+BR8HvyN0ChtLxyNCjQwMQcbUUzOGr6uDoHxH+HaHhWfzmtjbN/vq7kjq+6T4GH3MhGGYPMuCmqhej3zkCkHzsyq540lEiccYgMGaYwzDIK+8kz+50cNSFGIELRYLlR9NmVdoejSihDo8jvSABQ8cwMYe+y3YWeKjyrdcHHMeU= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB5PR02MB0775; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(601004)(2401047)(8121501046)(5005006)(520078)(3002001);SRVR:DB5PR02MB0775;BCL:0;PCL:0;RULEID:;SRVR:DB5PR02MB0775; X-Microsoft-Exchange-Diagnostics: 1;DB5PR02MB0775;4:VIELIbkqCv4V+HlKAm2ic9HEBV4TxKyf6+tzcNm1oxo0cHaHiuvnrrplDOvtiQDRg7/q1JNvSMv+Xp+LiePa3uReNBxBycOBY1A79dbFOZ3agI02armaPD6rpwG9VEGzIdxkq7UMhnCVdbfLEjYHOstWMowa0ZLv8WWk/GxprMH2SVExGoal8ASOXAS4f/daaXl8t3xAUNCUy5gb6keH3CsIm+vODgNBaYkahIZE/7WQRUjQb+Zk2W8EV7TEITrPsXaiZl0aNM6frxjGrd9qt5mcVf+XVtZrD6TYFnFziAVFlVOaoUoun33jMAI4bXia9790F1IPoru+6OwxE9wPBaJLPdVmiTP9jhEZJ72M0E4= X-Forefront-PRVS: 071518EF63 X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10009020)(6049001)(6009001)(199003)(377454003)(479174004)(24454002)(52314003)(189002)(101416001)(2950100001)(5007970100001)(5001830100001)(5004730100002)(65956001)(87976001)(42186005)(47776003)(5001860100001)(23746002)(97736004)(80316001)(189998001)(93886004)(5001770100001)(122386002)(5001960100002)(40100003)(19580395003)(4001350100001)(92566002)(64126003)(19580405001)(50986999)(4001540100001)(64706001)(87266999)(81156007)(77096005)(86362001)(54356999)(68736005)(36756003)(46102003)(77156002)(59896002)(76176999)(62966003)(33656002)(65806001)(15975445007)(83506001)(65816999)(105586002)(5008740100001)(50466002)(66066001)(106356001)(18886065003);DIR:OUT;SFP:1101;SCL:1;SRVR:DB5PR02MB0775;H:[10.7.0.41];FPR:;SPF:None;PTR:InfoNoRecords;A:1;MX:1;LANG:en; X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1;DB5PR02MB0775;23:4AtcLkVopSd3kS1whOyhv+alc+9uuijySI5jt?= =?Windows-1252?Q?Eyhim+kCSU5+3N/1vKQXwIqKaqcz3/G4SxkWDWwHCiOlZv5mZ3w1zya5?= =?Windows-1252?Q?LoC9iuxVSbEYsjZNOnwYq4jCbofJ7dlKZF7YHhPf+Ws9O4F74GwXNKf8?= =?Windows-1252?Q?C4vs5gYXiHmWGw2JmoyvzuQSbJ41P1xkS6fnwQdjliuslBBRGJCAiQVr?= =?Windows-1252?Q?EJ8BQX2TcmUxPTuvOEl1Lq40ivD8NFWqzXIfXkkKV50nRfESECvtRKSe?= =?Windows-1252?Q?twXy+a6frmLTc7yyc1Sz/cRX/nW6nNcrDYIf0wg7rp1xzyM0jDfbPucT?= =?Windows-1252?Q?q4r7k291XmP/GY0LEcTgmFTFZmDBLZzoPEgqJaen9ckyDMpH69t7+odn?= =?Windows-1252?Q?4Lwyfaag9QQI5PRCKpw8QF4mrDdtY7V6fGaOc2/ZL8rHU2nnwQ9Vmp60?= =?Windows-1252?Q?j/xJOY790uCpYMFzg4o2gefUx6uwh+C+YMH5/ltwL1q3hFGl6/tn0rbW?= =?Windows-1252?Q?DPPu4lo46odyVqd4Nfyz6SUl/4XeSUYzqdA4+u342akhRv2sHbywbvom?= =?Windows-1252?Q?hYJeCShL4PcODtco42veCrrfpMt4P8gXo1kkNSDFROHcVUnO4nqjwfqI?= =?Windows-1252?Q?WwPo1pr41dgIMVQyTvQtPpJMn/tyqJslXEbxlMszcB/g3Pvht0bIVmj2?= =?Windows-1252?Q?hbJRYSCftoE+54B86uTc0XXtZ0ijXO+r2PRFNFGBOcB/4mjHny2IMOiP?= =?Windows-1252?Q?lzvRGISnorf/r2zjb+SeLzmiw+jSz8Fl6rlXmoSEwxMZ4xhDqnkNqVpm?= =?Windows-1252?Q?0M4uuF/Mb+0RJBp1EO4Uq1Su3IAABY+SBuNKO5B2NlEoVN9laz4JXjwX?= =?Windows-1252?Q?IXYAZSxrCfxZNLciDIT01UizDo28+Di+A6//Sf//bSomU115w67g0/Qx?= =?Windows-1252?Q?prOXt8Nd3fubUdc/1pascdFUuYRoBVDw9W4Jr0xKfpScngJ541giDvmV?= =?Windows-1252?Q?6/U6duUMVS3JN2PMbD0D6ZOsM+ybOLt4bfBK14C7Gi7lo46sh22OFqsX?= =?Windows-1252?Q?usisp4Ya5gvKBj8yFCJ6QEno8v0d8Q6kux9uHc31fKRXYDzBmw4eJwyG?= =?Windows-1252?Q?XsCYo+FtzBvdHdk9YK/CcXMsp2LPg+KugNhMq+khOTaMGP0qM1PJ/1ps?= =?Windows-1252?Q?TBO+TE/ESO9gvjraads+8KXrBt6dZVDiYFo8I42YHqS7SKdGkpLj0cEj?= =?Windows-1252?Q?fVfK0oJh0gPT+SCCEJOBDsXLvPdG7yi/5i5GzTjqWQinn3rEha2W7+ef?= =?Windows-1252?Q?eUHdkYfPqpQnl0v7qO3wdj7Rct0nJ8s6SAkSJnSOXcMRrIuQ0U9xYOFx?= =?Windows-1252?Q?hILEPK8xtyJpQwbEgqzucmymc6okXtK4neb6RT+WQWb4L+dgpsd+HyK4?= =?Windows-1252?Q?EzqSyhTm1LlD6qvycLc9bcQtzJ3Ud6LsuoXhToxKmI1rZJs+QvnkecNF?= =?Windows-1252?Q?0I5/zRzFSqqOTDvd5DdDWqyvmPXv5gL4TRVAA6rUSaQP9I3f2zDbRVzC?= =?Windows-1252?Q?FaZmseWikoopga7ZAwtbk6t7hGcHuQO5Np0aHkN8SXCNDW2PdO5rBHQa?= =?Windows-1252?Q?gKJIrb2kSCgAEjlhv11GgWjFadvN8noOnvdJv9PVBS3?= X-Microsoft-Exchange-Diagnostics: 1;DB5PR02MB0775;5:b1mLKEXuhLe9RpuSU+GBUQ89HQrnI0tB5UFJx0yw5fnMLner7iWRmi+A6heQPKn9vaieGKkY5knRTzDTXRX5JSaplDKdcxOdGUCjPEukdbLb3IEm4dnacj6a6VNUp2mtV4jfcHAvQGZ4y/ofwm0Lnw==;24:z8Kq7FZFvqGFGmiG+SEaXLQto+X42fyt01JG46Y2bkpKPHWJHK8qc9234UQh8fZkrxoxDrnTkjIndppTbqSoZF7WnAvMzBdm2pptC7YJECA=;20:wEuSA0KPMDMy3wOYt4NW8cFylQc2H0S10bS/8klkKKmHrinfKZT9/7aXNQMtTmZRXDTMMotBOxI+poz8iqwaQw== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: ezchip.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Sep 2015 20:58:42.8841 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR02MB0775 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 09/30/2015 04:25 PM, Thomas Gleixner wrote: > On Tue, 29 Sep 2015, Andy Lutomirski wrote: >> On Tue, Sep 29, 2015 at 10:42 AM, Chris Metcalf wrote: >>> 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? So the model for task isolation, as proposed, is that you are NOT trying to use kernel services, because the overheads are too great. The typical example is that you are running a userspace packet-processing application, and entering the kernel for pretty much any reason will cause your thread to drop packets all over the floor. So, we ensure that you never enter the kernel asynchronously. Now obviously if the task needs to enter the kernel, you have to allow it do so, and in fact there will be plenty of scenarios where that's exactly what you want to do; but for example you may have a way to register that a particular thread is opting out of packet processing for the moment, and it will instead go off and use the kernel to log some kind of information about some exceptional packet flow, or some debugging state about its own internals, or whatever. At that moment you would like the thread to be able to use arbitrary kernel facilities in a relatively transparent way. However, when it is done using the kernel and returns to userspace and signs up to handle packets again, you REALLY don't want to encounter some kind of tailing off of timer interrupts while some kernel subsystem quiesces or whatever. So we would like to spin in the kernel until no further timer interrupts are queued. In the original tile implementation, we would just wait until the timer interrupt was masked, which guaranteed it wouldn't fire again; for a more portable approach in the task-isolation patch series, I'm testing that the tick_cpu_device has next_event set to KTIME_MAX. The discussion in this email thread is that maybe it might make sense for one of these userspace driver threads to request a SIGALARM in 10 minutes, and then you'd assume it was done very intentionally, and figure out a way to discount that timer event somehow -- so you'd still return to userspace if all that was pending was one timer interrupt scheduled 10 minutes out, but if your hardware didn't allow setting such a long timer, you wouldn't return early, or if some other event was scheduled sooner, you wouldn't return early, etc. As I said in my previous email, this seems like a total corner case and not worth worrying about now; maybe in the future someone will want to think about it. So for now, if a task-isolation thread sets up a timer, they're screwed: so, don't do that. And it's really not part of the typical programming model for these kinds of userspace drivers anyway, so it's pretty reasonable to forbid it. -- Chris Metcalf, EZChip Semiconductor http://www.ezchip.com