From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753562AbbJHAec (ORCPT ); Wed, 7 Oct 2015 20:34:32 -0400 Received: from mail-db3on0094.outbound.protection.outlook.com ([157.55.234.94]:30016 "EHLO emea01-db3-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1753487AbbJHAe2 (ORCPT ); Wed, 7 Oct 2015 20:34:28 -0400 Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=cmetcalf@ezchip.com; Subject: Re: [PATCH v7 05/11] task_isolation: add debug boot flag To: Luiz Capitulino References: <1443453446-7827-1-git-send-email-cmetcalf@ezchip.com> <1443453446-7827-6-git-send-email-cmetcalf@ezchip.com> <20151005130732.639d81da@redhat.com> CC: Gilad Ben Yossef , Steven Rostedt , Ingo Molnar , Peter Zijlstra , Andrew Morton , Rik van Riel , Tejun Heo , Frederic Weisbecker , Thomas Gleixner , "Paul E. McKenney" , Christoph Lameter , Viresh Kumar , Catalin Marinas , Will Deacon , Andy Lutomirski , , From: Chris Metcalf Message-ID: <5615B9F4.5010902@ezchip.com> Date: Wed, 7 Oct 2015 20:33:56 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <20151005130732.639d81da@redhat.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [173.76.21.154] X-ClientProxiedBy: BY1PR14CA0007.namprd14.prod.outlook.com (25.161.91.17) To VI1PR02MB0784.eurprd02.prod.outlook.com (25.162.14.146) X-Microsoft-Exchange-Diagnostics: 1;VI1PR02MB0784;2:goX4N4uFO1gX4ppbTWMs8YD/5RPu5t+0adoVzje/tidrzh/LtJLvRmCdW1+Q4epKTmkiZGGIkUw4WlwCt8hiokO0kv+T6ed/LWvRFy4fByzvHeftq+Qj+gj4nxiz8FHCIA0KZYdmmimVY6+Sxc0E9h7z23dY9Rpllnozi3xSKok=;3:jtMpQcRoQwd7rREfsvURUopJUrDtzRv0a8FjB6CTx2u5S4LfE35qlKF8uQPIeWEa5nem8WAdVxdnuXlasMVJCF4t0XUeATf7sXMKbrbVvvIeCqDb/iO7PIMnacvb+el/4XANUGhDlghKnErYjhf5EQ==;25:K4zE5ijljmcI5ZAS2S+ynxiIUstM2oWbcBWjynLQDDjBZG91FKj4oisBgAXtBQFSi0ffr6IbsDrR6PvP20sgp0aST9TSOCcQVcKkkjx/Yi0zZnqcNTtsHJcbKfEEtmv7l9iV6qOaUX/4mNPs6kIjDyLoYiQ92jT4BbZ1DlJk1/jOQuwbfqXZ72KPV4njl4OFDjqnOUaX888lgbMYlLVcbbTNxNzS0DuRXBJOkolYJzRVnUBg6NTl6SE6gU1alcd8o/CA5ZWcr0WzZm4101PDfw==;20:aARmRROENY+sUK27OPRzraOYB4g4g93+Ajm6BANA9TCcsBOOr8Rpf6r/HiCkwVilsnosWS4JYrYy5wdu+pXJzXuwpUDLc43/GBlzDydY9cMnSQBRs+FooXOG+NFBXdmRBtZXjBRD36fJSs/CdeYnUDvZGkCOj428hZpKBlKRQTk= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR02MB0784; 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:VI1PR02MB0784;BCL:0;PCL:0;RULEID:;SRVR:VI1PR02MB0784; X-Microsoft-Exchange-Diagnostics: 1;VI1PR02MB0784;4:gfzXIFnz/FKAV2pjWEPF1/5bQkJRNDMGA/Vg73yjJzzL1SUp72PkzQvWjZauUUa6gb/sRHWTXS9tb1NAqFt1nBE9A5AuP3adITVKG/wrq+10d+66uv5wzrNOSr5EtMDEI16/Xlq9V3J/EPiHrNRW7GQffL6rbgIbaek+iSmsKI9iFv7/zzvew2Yk8pYCK/OP91+MwjEkF9R4k8sHoYohWHTODRZeQjiEG4p6rjD1rfVxgVl7zV2ZxiNZHn7/ZrAsHUe7An9b6bplyC4SYSiWgtPdxN9E/qdq5FKYbriKUDacAv2vTuM9qib6sekMEpztY/bm5wrHGEW1gObifaJeGN29jYfdqGGxfy9fFYfIrzE= X-Forefront-PRVS: 0723A02764 X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10009020)(6049001)(6009001)(189002)(377454003)(199003)(43544003)(24454002)(479174004)(4001350100001)(97736004)(15975445007)(33656002)(5001960100002)(36756003)(87266999)(81156007)(54356999)(76176999)(117156001)(64126003)(59896002)(5004730100002)(2950100001)(42186005)(50986999)(65816999)(5007970100001)(105586002)(64706001)(47776003)(65806001)(40100003)(101416001)(66066001)(122386002)(189998001)(106356001)(65956001)(87976001)(92566002)(46102003)(19580405001)(80316001)(23746002)(19580395003)(77096005)(5008740100001)(110136002)(83506001)(86362001)(50466002)(18886065003);DIR:OUT;SFP:1101;SCL:1;SRVR:VI1PR02MB0784;H:[192.168.1.165];FPR:;SPF:None;PTR:InfoNoRecords;MX:1;A:1;LANG:en; X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1;VI1PR02MB0784;23:9AXW6WT9QVkrJYWoyQJ6RKiu7+qnF8Y7DlUev?= =?Windows-1252?Q?jJcBrMY8b9n8iI3YBzi0gGj7I6V78d0MoF5a/vgrqDomk0UkWL2ZeuL5?= =?Windows-1252?Q?rFpVXODknJVDP78SVd+z1ejcTdNgPuJBqldCSOXUwPzaxaJTeo1WFKW2?= =?Windows-1252?Q?5Kncj2LATm8Veu9tMqID12DLyRFIk/MlcGfjwgSx0X174T4Emb+eRnS0?= =?Windows-1252?Q?/I1bomjogd9ph+Gx6yEpHnteWEjn8tUHYxoZbUtbyZ2mNOi+2L49YlkW?= =?Windows-1252?Q?N0hsvb1K7xhUQ5fWLBLZHwSBjY0ej7jDDdvI8/lPr2IaseHCoOPAw5ck?= =?Windows-1252?Q?aVfvVd82GD5NT19FMYJxcDr8wpWa4onc76BM9Cjj5sPYSUOy1pNS4qDf?= =?Windows-1252?Q?zvrUMsKxO5ZYVElR5fVI8f9Gkvxwxvkc6W+5gzpacg5+nHfg5pCtV5bc?= =?Windows-1252?Q?r1gh9ycsMWEsFMRgxuRVfcgEcCfaw0EoANY3g683ZTYOKImscAmlkI7i?= =?Windows-1252?Q?MYH4+xJdJi5Iix4DnF1tzP5UimxJOUOnIf3J64NQiKSHeeYYalSKFHqb?= =?Windows-1252?Q?0zzlUCvE40USvIRJ83nvokAlTIt/0RKlc6NRRsQladB4kmXo68fsjnCM?= =?Windows-1252?Q?Xq23YSC/3bQW3+yITsM+pjr2OYiILV9CP3NTJXz3/TiAWTghLq8NoBC2?= =?Windows-1252?Q?6gFKoBPgD7Yz9pSI7J87wvjk/U0WRaYb9UW7/mQfwlCyPbce6d9RMmTG?= =?Windows-1252?Q?HXk11fsfMRlHo5BS+mlf5ioZPODPMcOI1Q1ZiTWu1JwXGXBpJAIbwuvS?= =?Windows-1252?Q?V9PdnOdIJdCxedxZt7agzVM4+Xjm0F1k5TzbhqYHXSN1Y+YkzSO+wySV?= =?Windows-1252?Q?7TGDGqQ9K39u0NNlNEvzsGuAsEfqr0lk13WytLYw5Bek1KeM/83LekMv?= =?Windows-1252?Q?eGy718gFTQOr7IxVhVIl2nsdXqRy/uGdBFw+0KrRhkFMzOuWvhSsRZ1D?= =?Windows-1252?Q?9N6I5FIcvhfAEu0P6qgyLiZz1wGR2iBxjvRfWjcbezvdC1xviFGnlCx7?= =?Windows-1252?Q?Yevk4oFabRMLXDsqjV9esQ9JTzR8CO4QYImviZdHYxoBAJhQk26DcAVE?= =?Windows-1252?Q?OalBP9z199J7hHW1UujPwH4p2qEG4cAdt1SMdQ1hDR13HcBlIZ8jl4GT?= =?Windows-1252?Q?lIiIjWD2NAsdM4rNOGxTxX+gG9SXem+yBjs7waWaFyBEV2CE89YQNYqq?= =?Windows-1252?Q?Kdt5++t83hNlUo7fiOCX8izrhs35CY/K01Rh51A4drsX3S1m5x2utlWS?= =?Windows-1252?Q?V0OU0q3u2PPwD17GHVdV40DtIgNN989DOgMoJ5LSqtOgx3gBJIVhRhdO?= =?Windows-1252?Q?uVVzGYlOreHQjhPa4u8YHi1iWMxHZZW2okIX/cL3h5/NFretZ0HH+2AJ?= =?Windows-1252?Q?KAkGACdkoIN/l39wIJQComoADIsr4phPKEZnPCl8g=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1;VI1PR02MB0784;5:d9Vd6qShzgzNhwp6pt6a5rK7zk0f2rO34vklLZ0VBW31lRgPmIHU8cvB1Nrym70vtqNh4aptuQx9ATxBV8WY4pWdZP+gk+JIFzk/ge8eXs0Xc07Kf2TL7jotS/6ccIV8adl/eTzw+ShdHbRsg2dT6A==;24:wbwdAtIh2YGJOK3QPhcAGZb8BpWoaG9uUYYC7Ct84zgARYFe9/SQgfpIghfZ8nJrDxq0taPwdslwCFLioGVjAyBxCSaf+tNc9uraqqqwQ3o=;20:nZNWmjHQSr9Q5+AOABw8O5OnQeby+7ycmRfKIV7Ycwx/r8CeYPDabxYLyo6HsM1uZ4NZ2CA35Uu9mpXaO1LYHQ== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: ezchip.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Oct 2015 00:34:12.3565 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR02MB0784 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 10/5/2015 1:07 PM, Luiz Capitulino wrote: > On Mon, 28 Sep 2015 11:17:20 -0400 > Chris Metcalf wrote: > >> The new "task_isolation_debug" flag simplifies debugging >> of TASK_ISOLATION kernels when processes are running in >> PR_TASK_ISOLATION_ENABLE mode. Such processes should get no >> interrupts from the kernel, and if they do, when this boot flag is >> specified a kernel stack dump on the console is generated. >> >> It's possible to use ftrace to simply detect whether a task_isolation >> core has unexpectedly entered the kernel. But what this boot flag >> does is allow the kernel to provide better diagnostics, e.g. by >> reporting in the IPI-generating code what remote core and context >> is preparing to deliver an interrupt to a task_isolation core. >> >> It may be worth considering other ways to generate useful debugging >> output rather than console spew, but for now that is simple and direct. > Honest question: does any of the task_isolation_debug() calls added > by this patch take care of the case where vmstat_shepherd() may > schedule vmstat_update() to run because a TASK_ISOLATION process is > changing memory stats? The task_isolation_debug() calls don't "take care of" any cases - they are really just there to generate console dumps when the kernel unexpectedly interrupts a task_isolated task. The idea with vmstat is that before a task_isolated task returns to userspace, it quiesces the vmstat thread (does a final sweep to collect the stats and turns off the scheduled work item). As a result, the vmstat shepherd won't run while the task is in userspace. When and if it returns to the kernel, it will again sweep up the stats before returning to userspace. The usual shepherd mechanism on a housekeeping core might notice that the task had entered the kernel and started changing stats, and might then asynchronously restart the scheduled work, but it should be quiesced again regardless on the way back out to userspace. > If that's not taken care of yet, should we? I just don't know if we > should call task_isolation_exception() or task_isolation_debug(). task_isolation_exception() is called when an exception (page fault or similar) is generated synchronously by the running task and we want to make sure to notify the task with a signal if it has set up STRICT mode to indicate that it is not planning to enter the kernel. > In the case of the latter, wouldn't it be interesting to add it to > __queue_work() then? Well, queuing remote work involves sending an IPI, and we already tag both the SMP send side AND the client side IRQ side with a task_isolation_debug(), so I expect in practice it would be detected. -- Chris Metcalf, EZChip Semiconductor http://www.ezchip.com