Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752642AbbG2RYg (ORCPT ); Wed, 29 Jul 2015 13:24:36 -0400 Received: from mail-am1on0090.outbound.protection.outlook.com ([157.56.112.90]:37550 "EHLO emea01-am1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751639AbbG2RYe (ORCPT ); Wed, 29 Jul 2015 13:24:34 -0400 Authentication-Results: redhat.com; dkim=none (message not signed) header.d=none; Subject: Re: [PATCH 08/10] posix-cpu-timers: Migrate to use new tick dependency mask model To: Frederic Weisbecker References: <1437669735-8786-1-git-send-email-fweisbec@gmail.com> <1437669735-8786-9-git-send-email-fweisbec@gmail.com> <55B26E74.5040803@ezchip.com> <20150729132343.GC11554@lerouge> CC: LKML , Peter Zijlstra , Thomas Gleixner , Preeti U Murthy , Christoph Lameter , Ingo Molnar , Viresh Kumar , Rik van Riel From: Chris Metcalf Message-ID: <55B90C40.5090000@ezchip.com> Date: Wed, 29 Jul 2015 13:24:16 -0400 User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <20150729132343.GC11554@lerouge> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [12.216.194.146] X-ClientProxiedBy: CY1PR1201CA0022.namprd12.prod.outlook.com (25.169.17.160) To DB5PR02MB0775.eurprd02.prod.outlook.com (25.161.243.146) X-Microsoft-Exchange-Diagnostics: 1;DB5PR02MB0775;2:pt4v+ztnEZDZDD5a3tcu1pTy30eRyBAwerGztapsbbtRk2VObnl/BNF9+fn/lhaoOBRsepK8dWlGXsnxi0tGfpdO8nPZmyYldE9/lL9W7+VfpplUwu7c8qJo8AySFfCjzdLzaDnsI3xuKc5ZUIQX/A7gFM9JBfYLhV3yErf7Bu8=;3:5kT7/PLFckzf+AYxKfFvMgING1yK4s23J4hqdEAE2UXxa0aaCY1ZCKVOq+iTVG0daWgJTtAzBFs9id3Votu/VjMV+pJJA5sEJ8fNtpw32aLKjnnD1uS4TQefsyyP6Q8feH4ZyWZYT+ZTFEm70Pcvyw==;25:fziUyhuisRkESSIUcEVq1qriVUiyNJI+Nc2AgZZHPGy01XPRpb0Y6AP+Wk+P4MP2H8Rsm5bwyU27lBLxgARdPq8nlIp6T0A0b2z2hBaYqZRPZ5VfQpzxkoE8jGgdIUV/GRtjMwW8VKJ+RHw2GXJGfrWU4gLQn6Wku1B2306c34DW7CegBrZevGEM8WFx9ZzaLTnqm6flNVifrIB085qn4Ek/I/SBo59XNkl/ugBxxz8Un1L7Nh0dICuaujEQOXvH3epTgbxfcnUbJFEwe8tMVQ==;20:iAr5vEPm/6wcZuFeGhkFBHxYMNGov4pxHQbsfIG2rQsDAT3RzcKsn9fGcK5Z2ZhYZWxRSfLHM1bB72jYS06LbA8lmNsXUe32Lqtw3bj0hmaf5iCZTdqW0mcsHnrsBpbMYCASQZdFmxQ0x5EnTS0Bvmfo86jKq171C1Ksxu3BLUM= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB5PR02MB0775; DB5PR02MB0775: X-MS-Exchange-Organization-RulesExecuted 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:DB5PR02MB0775;BCL:0;PCL:0;RULEID:;SRVR:DB5PR02MB0775; X-Microsoft-Exchange-Diagnostics: 1;DB5PR02MB0775;4:nwjJ46ZRqJs9qsLci0jfm2+hDePXRIlQspYLPtJh0mTWoUREBrLiLlGaJfQ2e7HNclMHztALypa1ECMeIjqgzD7CBsze5XgIPbInf9VWBxhSpGnpck3TdSfVGoBwVjtpk9xqgFXFDGOQxPUhHP+Ud9JKEHcqbPVjETR8lJCUqEE/Ha8E+lSdhnzz5tsPDJ43qWxlLSIv7S7r+IyN/Tkj69RHNwT2BhwfdGs/xBbeDudEqt80bhSbe7/K8HIqupo5V82otU4/yLq6Em6AMwkdccFioZagKFOq1RSMqFlfM1E= X-Forefront-PRVS: 0652EA5565 X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10009020)(6049001)(6009001)(377454003)(479174004)(24454002)(93886004)(15975445007)(47776003)(50466002)(86362001)(42186005)(33656002)(19580395003)(65956001)(46102003)(65806001)(230783001)(80316001)(66066001)(2950100001)(36756003)(76176999)(77096005)(62966003)(50986999)(92566002)(110136002)(83506001)(1411001)(5001920100001)(5001960100002)(40100003)(122386002)(77156002)(54356999)(4001350100001)(189998001)(23746002);DIR:OUT;SFP:1101;SCL:1;SRVR:DB5PR02MB0775;H:[10.7.0.41];FPR:;SPF:None;MLV:sfv;LANG:en; X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1;DB5PR02MB0775;23:gAqX3MOFawoYZHimn2yg/K6fbENWeQraXoo0B?= =?Windows-1252?Q?re0tPKbjmxbctdoL3dWD8R+2CFeNcuA6C3R+spidRcOJXzjXimgU/v7f?= =?Windows-1252?Q?0CWPTXChEbOED6Z4M4ELDEuL/LFKvp+BiE8Yqjbquj6GzWTqamzg9jeR?= =?Windows-1252?Q?UxJDoqTW0GFb/XNDP+/893sj9D5VgiLty/WaTi7bTmkgttGSzhRXfDlG?= =?Windows-1252?Q?+3rTZHSWER0zweQJJn/V08CeTIlcywoxfsg7pUwpnF7N/81Lv94gmuXp?= =?Windows-1252?Q?g7gV9ZpDxCUF5ctj1cq4SxiCIwMopV3YFBhwZmtmciONMrw5vw5yeJWD?= =?Windows-1252?Q?CcZnFywSAJxFib3fyIPugNYc25nWJJawldRflWnJphP/wd3qfPLZhlBZ?= =?Windows-1252?Q?uW61HHMH5jNCGtgmx/SdMaLCgnwj238encYVC/Ilvp70f+iT5U46EjKG?= =?Windows-1252?Q?K3dhV+Bt92yfl1oO2ubFHqE+3TS487mspn+kCqUlU5FymH1+bTwFGwrS?= =?Windows-1252?Q?2Lmp2AdCNaUvJkAHSZIs4elVzxibJU+zem01EkTpKMvCcEBlBFZWIqZh?= =?Windows-1252?Q?+CrerjoiTP12dKjt2S3cWzgAfR00ZOIzqs6s27QaJLsk6RiPRLXnoQoS?= =?Windows-1252?Q?ISGETESMlKEwGvoBZ8M2Dc16Vb5WlOZfdD7O4BH/rqbLNfqZ9wc68p5U?= =?Windows-1252?Q?nPywJUcHXUvq8+6or/ERhp83Q2P90l1X5Z2Z6gkEmQxUBt2lsQ1cwG61?= =?Windows-1252?Q?dj6svRsVee2AU4yToKDV+s7P0wpgten3+6jd7nRKUP4rQsw9LXVEu9QD?= =?Windows-1252?Q?cdkuvUCRuZ5fhQiZYYQ8Ugkv9rZ6sbrTH31G1Z3N6yHj9XX9HBGa8Z+V?= =?Windows-1252?Q?Iy79ku6R8/DBWfILiwDfKTZg/rvbKJbINksYaivgvCdBasKEA+gmmULE?= =?Windows-1252?Q?YkJKLDZG6TP68TKApsI9pcRRzwtBOH3yLpKam4c/HKkl4etgooQQmUfo?= =?Windows-1252?Q?+CBcP1egYaSAFU9gC9iNeOZzsuAkthcLx0qpAQhl11r8l+2Pg3KiJjK/?= =?Windows-1252?Q?EKus3B9g/WPuU6f+Xvj7zk7UoGHZm3e8ebb?= X-Microsoft-Exchange-Diagnostics: 1;DB5PR02MB0775;5:7t+SjsLvm/lNu4CXFXARsUTXEDnz2zDbbszhlrVyr7C2pNKbQaAEt8yTaDR/fuaB313Op0VZi6TozThSmqYXscQNleRYlWJfi7p2wPiCwOIXf9F1C1d+EHopmt8W6izGDz4hP/E290Reyb0nVlPsPw==;24:h197RSHnqfK4ATNXNhlTKDckegEIaJkCHlvo7n3TLj/amd4trjDEZJEWvaSS36I+a/LPLNC5q7dFt+kjtZSDTieoIffQUpHRdi/aVM2Sq84=;20:2QAzu7cyzSEmPfB45Bo7HPsfjEt7QCgziSh7im/t2WAif/UxRhwEqq9oKgyV91RVVLvcqsDIjCGAEOOIFVvrKQ== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: ezchip.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Jul 2015 17:24:30.1220 (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 Content-Length: 3182 Lines: 59 On 07/29/2015 09:23 AM, Frederic Weisbecker wrote: >> At a higher level, is the posix-cpu-timers code here really providing the >> >right semantics? It seems like before, the code was checking a struct >> >task-specific state, and now you are setting a global state such that if ANY >> >task anywhere in the system (even on housekeeping cores) has a pending posix >> >cpu timer, then nothing can go into nohz_full mode. >> > >> >Perhaps what is needed is a task_struct->tick_dependency to go along with >> >the system-wide and per-cpu flag words? > That's an excellent point! Indeed the tick dependency check on posix-cpu-timers > was made on task granularity before and now it's a global dependency. > > Which means that if any task in the system has a posix-cpu-timer enqueued, it > prevents all CPUs from shutting down the tick. I need to mention that in the > changelog. > > Now here is the rationale: I expect that nohz full users are not interested in > posix cpu timers at all. The only chance for one to run without breaking the > isolation is on housekeeping CPUs. So perhaps there is a corner case somewhere > but I assume there isn't until somebody reports an issue. > > Keeping a task level dependency check means that we need to update it on context > switch. Plus it's not only about task but also process. So that means two > states to update on context switch and to check from interrupts. I don't think > it's worth the effort if there is no user at all. I really worry about this! The vision EZchip offers our customers is that they can run whatever they want on the slow path housekeeping cores, i.e. random control-plane code. Then, on the fast-path cores, they run their nohz_full stuff without interruption. Often they don't even know what the hell is running on their control plane cores - SNMP or random third-party crap or god knows what. And there is a decent likelihood that some posix cpu timer code might sneak in. You mentioned needing two fields, for task and for process, but in fact let's just add the one field to the one thing that needs it and not worry about additional possible future needs. And note that it's the task_struct->signal where we need to add the field for posix cpu timers (the signal_struct) since that's where the sharing occurs, and given CLONE_SIGHAND I imagine it could be different from the general "process" model anyway. In any case it seems like we don't need to do work at context switch. Updates to the task's tick_dependency are just done as normal in the task context via "current->signal->". When we are returning to user space and we want to check the tick, again, we can just read via "current->signal->". Why would we need to copy the value around at task switch time? That's only necessary if you want to do something like read/write the task tick_dependency via the cpu index, I would think. -- 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/