Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754379AbbHFRNS (ORCPT ); Thu, 6 Aug 2015 13:13:18 -0400 Received: from mail-am1on0062.outbound.protection.outlook.com ([157.56.112.62]:62834 "EHLO emea01-am1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751235AbbHFRNQ (ORCPT ); Thu, 6 Aug 2015 13:13:16 -0400 Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=cmetcalf@ezchip.com; Subject: Re: [PATCH 08/10] posix-cpu-timers: Migrate to use new tick dependency mask model To: Frederic Weisbecker , Peter Zijlstra References: <1437669735-8786-9-git-send-email-fweisbec@gmail.com> <55B26E74.5040803@ezchip.com> <20150729132343.GC11554@lerouge> <55B90C40.5090000@ezchip.com> <20150730004444.GA14744@lerouge> <55BA7C6A.1050602@ezchip.com> <20150730194519.GA24607@lerouge> <55BA8096.7030601@ezchip.com> <20150731144954.GB27875@lerouge> <20150803171243.GW25159@twins.programming.kicks-ass.net> <20150803173936.GC26022@lerouge> CC: LKML , Thomas Gleixner , Preeti U Murthy , Christoph Lameter , Ingo Molnar , Viresh Kumar , Rik van Riel From: Chris Metcalf Message-ID: <55C3959E.9050405@ezchip.com> Date: Thu, 6 Aug 2015 13:13:02 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <20150803173936.GC26022@lerouge> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [173.76.21.154] X-ClientProxiedBy: BN3PR09CA0026.namprd09.prod.outlook.com (25.160.111.164) To VI1PR02MB0783.eurprd02.prod.outlook.com (25.162.14.145) X-Microsoft-Exchange-Diagnostics: 1;VI1PR02MB0783;2:XYB8sx0cVcvFCGSaaRMekSn16WasOCl14ZkUvzR1rrVJRB2SaaZDfV/j54Rx8m/fzmyDd+wOduzl2bYo2k4x5MNjlz9+GLedyEJF4Ne9IKB6oGnDSx1nQ4iX7D0pUVFqLm+9YGdlXAenTA0FHT9xhIcRQi6xknEUZtNiagJMAKk=;3:rcU7FrZEb/62eU9suCatieoTDowsooHXIG6Wq9AER+cky1UcaJjalagk0vUQ7WPHd+f4UmKh4U/6RJ2Euhcfyq3JHHgST7GzyMGX5kwlfusQJtbwPNjrlNnLNx0c7UJdHXsFve1vZ21wii5uQWjymQ==;25:P/9SrinGDUOCxmiZTcoOf9qwVYX6VwbQdspecv9e2LDsG9oj2WKLFXXWxrp1yoWYEJXyPTsUziPiflJ8xBb+oNihG9bRK+hWx/TjYHKWfFlFpYJGNuFJh0lYe0TFwvfv8cSMi+irvlcEI4WmnC784a59aIlA23T6AmNDGV7KaRh3X91yHDJgGqyfWaNs/OTfu4kjiiqDdn9FbBTobtl409yYDiHloMQ4JN7DLdrc3pbpMSRdSz4ypR2y5RZ6VCHUM/OqSg53Pe91Y8ELRAod4A==;20:23Y4cHVoqqFUITi0D356S2Rx8vmSArfVJIVw7gg96WY9SCny6alArirOjuUxMCIX97QwLAya/W0pZe4aX9B79mclCzWWeg9CzxN9WWAXi65IfnOlNU5HcJ80cy9XBn7IH/zDR7F0KBqmygNlCd7qde5A8HHhupYsyy54OIdiU+o= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR02MB0783; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(601004)(5005006)(3002001);SRVR:VI1PR02MB0783;BCL:0;PCL:0;RULEID:;SRVR:VI1PR02MB0783; X-Microsoft-Exchange-Diagnostics: 1;VI1PR02MB0783;4:k9td8ZF5KZGxThVKDwE7e3Sj0BKKPF0/S/SBL0GLgt8KY9HoRH7SNwKPb75R1+B+XpHstmuhtMw7fOrubvFA8tkDqSQGLOKXZ12BGvOLlM56bvFNn5bnGHJQUQN+YztdvsjpvN7xTh91VK7m9AMcspNAYMuICeGIiCZk75gytzbU1HpjS6LLGUorQ65pLWd1kkP/HXw61J8A5kpZ48brCIaypU72xeW/X/k31xCGdsQr+9rYs9CwykhiBLFTwRwTnTxQwrcdqXs2FTBJ1ngFt81SGsNRkG4AxL/tJBkx2XI= X-Forefront-PRVS: 06607E485E X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10009020)(6009001)(6049001)(199003)(24454002)(189002)(377454003)(479174004)(87266999)(54356999)(46102003)(87976001)(122386002)(76176999)(50986999)(68736005)(92566002)(86362001)(15975445007)(93886004)(62966003)(33656002)(23746002)(65816999)(230783001)(117156001)(36756003)(2950100001)(65806001)(65956001)(66066001)(47776003)(77156002)(40100003)(64706001)(80316001)(105586002)(19580395003)(106356001)(64126003)(83506001)(77096005)(101416001)(59896002)(50466002)(97736004)(4001350100001)(4001540100001)(81156007)(5001860100001)(189998001)(5001960100002)(5001770100001)(5001830100001)(42186005)(18886065003);DIR:OUT;SFP:1101;SCL:1;SRVR:VI1PR02MB0783;H:[192.168.1.154];FPR:;SPF:None;PTR:InfoNoRecords;A:1;MX:1;LANG:en; X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1;VI1PR02MB0783;23:paRo59xUsvvWNx+7eaH4GeSqOcOyiLeO/439b?= =?Windows-1252?Q?UwzYUWhqKFH6309x1ZBVjsnjd0RgIrPTm3saGt8eZLF+0y4uMwIOK9FI?= =?Windows-1252?Q?TT39e9H7jUnwr8WJTNQSvctuFVXM8KVI7DOhf+bIg/0IxNjwJAZNQhco?= =?Windows-1252?Q?4PeIJtzM0TjV0nzEnUOf/AH7yvPvLd8c44QpiFCav4rTIAI97YgraLi3?= =?Windows-1252?Q?w9+3a01r/tJIfrFK6VR3/26D08kJ+8anF29eXOGnzqf+vz/I1ckrQEJ/?= =?Windows-1252?Q?vlFn7MayyRCKfNwjnwoXBQvjjE6WPbpu/4qfezKcHrpL6PRshOKSF+HF?= =?Windows-1252?Q?e354etFZHh8AeLofvGp7Yjt9CU7TNXm7rgUrmVOMxcBhdP4ninlJ1xGg?= =?Windows-1252?Q?I05eAHrWEwnltDOLvt9I185VsINxLNR3R8JWbyHfZbRX8TGXH1Tl5MZC?= =?Windows-1252?Q?lPJ4CyfzQ/XQDax12q5X+kvO9YHpNsajCqiAQSQHfO1WobBzYky70Hu8?= =?Windows-1252?Q?l5qwFkR+Kb6Ez1ZE1YtoctChi+mVH8bV3fRYGlw69Xb1eiFDKFVb8gf5?= =?Windows-1252?Q?2Korvw9uC0NgOjweLGj8lNohshUeDt8q1MiVVOWFSQfSRebapea1WeK1?= =?Windows-1252?Q?hJMLyxRXGess6zo+xcV+VcRPomU7gc0zlnDeh4+kb1NCRZZtgMlZxIvz?= =?Windows-1252?Q?vVkE7dsNJOUKwrHCEaF2rLRY4uT3so8WfWIi5TFbo6DQR2ZoQQpqQwQ7?= =?Windows-1252?Q?w8Yg9YAukdxxBYL1uAQjiUhx+++XJAUO9q8TNRnxYqLAXXJn6Mdiix50?= =?Windows-1252?Q?6wNVuT2PkW2ZBUGWgqycJYATKlyNPmCPEERq30yqd599wzVNvON60CwX?= =?Windows-1252?Q?5RxSvWny9JgAbG+zdffvTBiqv7h0NAQ7v4j/P1f6bKGW6uMjy8RVba5X?= =?Windows-1252?Q?Dn7QSFOVv9ODdSJdLyYBQvurRWdq+pT/85JNQPKHdwaWuM8NDI6c8flc?= =?Windows-1252?Q?AMKOpPYS7R/Gnw7R9w4wT0iRZhxin3OTvTQSMzplyWkpREyQXN7Ogya/?= =?Windows-1252?Q?dKSSTBX4WJO59TxqhDtKWCEnRa/SjRrUCF8QfR96aJpk63AcSrTPodbI?= =?Windows-1252?Q?hoKRkPMohmy7hh4Kw8vE9LdG9WtlAxBNBulra6+JYeQtaDQe53e+rqHc?= =?Windows-1252?Q?k0udYrMjaAoOqSdJGrSDBbnjOh8SyNdjF9f/1okS5rPD3K4Yu/0JQjFU?= =?Windows-1252?Q?Pv0CYLjaYfxGgXvFxBmZoB78gQ6kkqnmDaHFeggH3/zkzgGPSso2dwtB?= =?Windows-1252?Q?WHEuXhlqQZmq9TJkpy1MIeSGKSYcDtEnjXuOEY0CtUMiStbXOwJQSPKE?= =?Windows-1252?Q?jy15+qIChuzBb6d7gijMTIbMhp1osPJOEdeilmZ2RqtivayopQZ4ntSy?= =?Windows-1252?Q?8xjzRbBWRaxX4sj1PsBXTLI6HvMYM+vYqCu0Fjsk8kHOzLCQNIf7otB9?= =?Windows-1252?Q?XITGEnBBC7ZZRHl1tEaHVKItYYaiBdA+MncauIWy1H/KUf3JA=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1;VI1PR02MB0783;5:sKrLo5OAxwofCaCElbOE/+RCUUncx/3KxQBJwJi55VQ2WPv29UhC9TbUDwFlH9yHtXhY6pyosidQfMQkn4DR9GWNCuJCqj9navkcV44YuQsP2LC6GjZPEEZDJOeUpvRaJuk/xm6RC5FuqHOxijhtvQ==;24:UTd2UdwUmJVW7nyk7jCpUo6Qt+rq2m08zs38pVOoXj5Ci6t0G0QrxNTL3280MA1Tt3QEoDCxqBj/s8w78xklM046rViNhrN2jilUQtQ5Atw=;20:m6WyBZ30m0ItPk7AGEjRdY5IkoxNVnqDqgsMgtSz1zeHLVENwkLkNnW+g61+6LJKvGZNLfVmyNo7W0MpN+B0iQ== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: ezchip.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Aug 2015 17:13:11.0462 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR02MB0783 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2220 Lines: 42 On 8/3/2015 1:39 PM, Frederic Weisbecker wrote: > On Mon, Aug 03, 2015 at 07:12:43PM +0200, Peter Zijlstra wrote: >> On Fri, Jul 31, 2015 at 04:49:55PM +0200, Frederic Weisbecker wrote: >>> Instead of doing a per signal dependency, I'm going to use a per task >>> one. >> Urgh, does this mean you'll keep the horrid tick_nohz_task_switch() >> thing? > This current patchset removed the need for that with a global dependency > for posix timers: as long as there is one enqueued we keep the tick. But > Chris and Luiz fear that Tilera users have posix timers on housekeepers. I think Luiz was representing a different class of users, not Tilera ones, FWIW. > But you need to periodically poll on timer expiration from a housekeeper. > It's not only about firing the timer, it's about elapsing it against the > target cputime. Oh right, that makes sense. Layering this on top of the existing offlining patches that you mentioned sounds like it will get us close to what we want, though. > Another thing: now I recall why I turned posix timers to a global tick dependency. > In case of a per task/process dependency we still need the context switch hook because > if we enqueue a timer to a sleeping task, the tick must be restarted when the task wakes > up. And that requires a check on context switch. Another approach might be to separately track nohz_full and housekeeping states, and then add a hook at task migration time. This is presumably much less frequent than context switch, and would allow re-assessing this kind of state when moving a task from housekeeping to nohz_full or vice versa. Then a global tick dependency would be OK when a thread was running on a nohz_full core (because frankly, that's just stupid, and you get what's coming to you), but for housekeeping cores we could avoid having to worry about it. (I admit this idea is half-baked but maybe it will inspire further baking.) -- Chris Metcalf, EZChip Semiconductor http://www.ezchip.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/