From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757678AbcDGUhg (ORCPT ); Thu, 7 Apr 2016 16:37:36 -0400 Received: from mail-bn1on0142.outbound.protection.outlook.com ([157.56.110.142]:64992 "EHLO na01-bn1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1757544AbcDGUhX (ORCPT ); Thu, 7 Apr 2016 16:37:23 -0400 X-Greylist: delayed 89067 seconds by postgrey-1.27 at vger.kernel.org; Thu, 07 Apr 2016 16:37:23 EDT Authentication-Results: kernel.org; dkim=none (message not signed) header.d=none;kernel.org; dmarc=none action=none header.from=hpe.com; Message-ID: <5706C4F2.6020108@hpe.com> Date: Thu, 7 Apr 2016 16:37:06 -0400 From: Waiman Long User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.12) Gecko/20130109 Thunderbird/10.0.12 MIME-Version: 1.0 To: Tejun Heo CC: "Theodore Ts'o" , Andreas Dilger , Christoph Lameter , , , Scott J Norton , Douglas Hatch , Toshimitsu Kani Subject: Re: [PATCH 2/3] percpu_stats: Simple per-cpu statistics count helper functions References: <1459566578-30221-1-git-send-email-Waiman.Long@hpe.com> <1459566578-30221-3-git-send-email-Waiman.Long@hpe.com> <20160404160228.GW7822@mtj.duckdns.org> <570584F1.10909@hpe.com> <20160406225424.GK24661@htj.duckdns.org> <57068395.1080703@hpe.com> <20160407160623.GF7822@mtj.duckdns.org> <5706AC71.3080801@hpe.com> <20160407185827.GH7822@mtj.duckdns.org> In-Reply-To: <20160407185827.GH7822@mtj.duckdns.org> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [72.71.243.60] X-ClientProxiedBy: SN1PR12CA0005.namprd12.prod.outlook.com (10.162.96.143) To AT5PR84MB0306.NAMPRD84.PROD.OUTLOOK.COM (10.162.138.28) X-MS-Office365-Filtering-Correlation-Id: 026239dc-4fd6-486b-5768-08d35f246ada X-Microsoft-Exchange-Diagnostics: 1;AT5PR84MB0306;2:i43Oh/4YeHoIRsqnk6b2w7/uX3fsP4V5dl5Op4+JUsWCgk3NKaVvpoglMjbsfDgzAm/pMCAEFEgxhHq8rhyr+SwsKb5V/QbjtDWCEFP73m5WcEcu94Ji0bae8i7VtY79hxxhaoDsYdO44/sEMFciQNg82obPgLbdqN8bgs54OB9YsW1zD87nIwiodsvI2Kis;3:muQl6Kw0Ds147MmvJTznNrQKcZ8fRfW3hXvXHwbBM9TD/vKK52Mr2jvKP7HX8yLG/HSnqAdx6GNo5YhO17zVhfxpWneKTCDO/xFZfAsRwWw8P/Tbv+ram3S+Qb/yaMgk;25:TM8y6cJaoQ2PQyM1D3pUIxpJYdhq4FsxxmXzyDFDAFD97Cj1r7NxJTtxxaZzMiM9YehKaHiNbJTvp6Qw5aXnKxS+NKyk1Y9Vph27KlwTPiltG90T38qIA8DHf8f0g35A+xG8JIxxsMxmK+q7RQBaY8eP0l9TtyFFj2dnNry739SMMy53UlfR44jaZu6rW4GTv+VNgZYJYkahzCFsiNLt+rEzIbSwdngzSvGOVM3qRCjlZsvz9SZiAyO1oBB1Dufll1bO5JttvjV1wDocabEnP9TSoBsk/pckDvalfqnLEekxfJR2jSGDzMKuWg8BA1n5+/KAbDFz8oQMCfIqoOnmbyKgd2OzUwWL06lXnDENSk/RxVlHl5EeT9s22dp2VokIGjUYVHUmMBqnWLMp26o3zQJXbbOvdAejK5SowA82QW1cNd6SRLKXsvJenhcqGVSIyRyu+c6Lmu4mEMjQ5sT3hMxqFR0D3lGlLuPhMltNjsRo/Uqa69QE5WdQzi9lq7T1v9KZfdQ6/YXlYlOEqDW8b0r5sTg4ks8K8J1+be4M3+pvNVFDzVoJgN2lkYahsnkzkantsMPenlpKpvgVuINvjg== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AT5PR84MB0306; X-LD-Processed: 105b2061-b669-4b31-92ac-24d304d195dc,ExtAddr X-Microsoft-Exchange-Diagnostics: 1;AT5PR84MB0306;20:a3I2fhSnerPGCIqCqAVq+bUJynDECdA9JCxKmfPgR9UXX+S3dw4yvpTplp722vrKOuAjUsBBSlmnFIxYR6+GwXylk7NsMBWbq8XTzOxT2BDUb7QV4Xo+eJV7rh1t4kQp7K7t0P1kKlCbqnaH1k+LRvpyEldlEQnM6UP8J5fgX0uuwQuqf+S9+fXnOk0R+tcy28BMAXX4FCVKttcCnjlE93Plu4Oh1N2q9j/sfjR0P8jlyZskVRGFu5Ztoq9uA5N7DS1Mg5HPU4L49BOosFaYjQRjJ72ZSY5lc/gNqOjM/M/26JK17pYTgAmxlGdAwriGZP1cXKuffKh2lqMC8VuQ9A==;4:rqXH4s5mIgAf+xKBg+EgKptlWElTW1/QcHXENlV+OakKWO69hC0D+ab/73tSdPkMqPXN4inPbJOL1YPOQRXUiFL+r1X7Fv2PM0f7Uh75mljhuRJERBfkcInnLz0hKRU6Nzns39hKkuO8P/oix/jgRWZ+LT0o39lqC+/hq220dW8FgMF4wg5P9mjb3AGLT5AlaojDhM8/ij/k5hA+LV0rDGAi2eqllm2bTCxBVNVu3nU+suYgRdOZe6TA66Y3h33Uajmsb2tTUT0QVcuH0SXoYD7wt16VWFOZWDelkewyQvr1E5G+k7OcuJSjIRMkoSu1YZL30uAhS+d3PkzgChIowgf7qg0wB3SryzMf7awAiq6QzY4xOiZELqrDYHxAWOQvsQxSdpT2azojD1fT+fl5/w== 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)(3002001)(10201501046)(6055026);SRVR:AT5PR84MB0306;BCL:0;PCL:0;RULEID:;SRVR:AT5PR84MB0306; X-Forefront-PRVS: 0905A6B2C7 X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10019020)(4630300001)(6049001)(6009001)(24454002)(377454003)(92566002)(4326007)(86362001)(110136002)(5008740100001)(36756003)(76176999)(23756003)(230700001)(3846002)(6116002)(2950100001)(586003)(1096002)(64126003)(189998001)(77096005)(2906002)(4001350100001)(50466002)(81166005)(59896002)(80316001)(117156001)(83506001)(42186005)(65816999)(33656002)(5004730100002)(87266999)(66066001)(47776003)(65956001)(50986999)(54356999)(65806001);DIR:OUT;SFP:1102;SCL:1;SRVR:AT5PR84MB0306;H:[192.168.142.152];FPR:;SPF:None;MLV:sfv;LANG:en; X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1;AT5PR84MB0306;23:nMF1hObb6LW8/qhf3Kn7fN1xUUF2HJtnXx9+JVj?= =?iso-8859-1?Q?HUP35lwprlVY/51XQd7HKmJbzSsptkiafa/xQiAekFXo8F4yXTDtHuYveG?= =?iso-8859-1?Q?CqBoi4Ih3HkO3CBJIJxv+pnrpn50dJgZtppSzMCuACL3noX0OOF/G/VFUD?= =?iso-8859-1?Q?yVjIlCwGlOx1M3jf2LHbBNfdG+OrY4T8eDVaxQE5Z/3A2qZFwEc58HjxyQ?= =?iso-8859-1?Q?hHq3IQzORcQ2Dhg+9c6Og5HCgbbD/o/l2+6xzVMebkQavn2BQPzY12PZwn?= =?iso-8859-1?Q?Gyb0A2ow6z091V7gPEdmab9PINc+5Ccqas3L8J0a1lMzqhRQYevmGTbHlv?= =?iso-8859-1?Q?Nodnd6f6UX2Ot3Ek9jdplKaMgcvzDDjuSBflaS5UqSP8a1r8YrzWwa3j3E?= =?iso-8859-1?Q?PtVltFpv5JdN1bUhvpCpNNjICP9uzFYdK1GgWHs96W+KY7ETv5lbFFNTI/?= =?iso-8859-1?Q?8b5Y6/3qs3WgPHjgEhVpBA03Dt0nylXK/uU6OScEBe3/BXu19RO4X2bBqE?= =?iso-8859-1?Q?8LAUZB+KWofzCA6fYwaZV8qrbWkaQrxgDWheIB1bdTdeNjpDeGr5WqTIRS?= =?iso-8859-1?Q?kxVB73j7+eD/hC8neJEpCi9LL7sUu6ed4QKJZl+jkRK+U9nI42/e/WvBoT?= =?iso-8859-1?Q?DUQlWM6c+xXJVE/7w6atUawJe6oOyplciuu9i0dDvzkmYiyyo9EIKJNNfG?= =?iso-8859-1?Q?6lNayCLdcP2JLeRPCw3/ZWFDQphdDXriKGeiF147xIwFco/UnxfMMCH+fI?= =?iso-8859-1?Q?1l416q3MxnTmC4aJnPIecxnAjHVNzBLAGC0bz5QZYacEsxCuNhpM+LDbBo?= =?iso-8859-1?Q?li9eLm1dZGXCykQp/uCisn9SaGoqZFqp0DkipV795MhqI8soSuTySr2d8y?= =?iso-8859-1?Q?mz7JC1YAEzhWmv5Kk6Ial4dUQ6AHLGE5mH6wd9wU2wJfv/P1kMuiuF8Rdr?= =?iso-8859-1?Q?Lss3rM6KK7eyPnB5YUx6+vasliLOXolThUYFmk1FAi+Zdf/lXWMYLEOwYU?= =?iso-8859-1?Q?/Zj+tu4wQYerAHKe9F/0jSgNA81Fi8XVMN4ILJrowp9CzLY7vDMyQgyl0H?= =?iso-8859-1?Q?mvs7VgG7aQKONFCPwhTte6w9OT2FK+tRZLGENPU2FJ4o+WUsg3mD1ncwJO?= =?iso-8859-1?Q?YNtSP?= X-Microsoft-Exchange-Diagnostics: 1;AT5PR84MB0306;5:09x+42Bf/t4EF4UqsN532BIMIZRxMJJCMUWjNR6hTw3tmGOYlnk9J4qMpruKbPvp4ZFvMi346G7irL4j3amXuyzX1bdpG4R0Aol5dq1QuJsUEh5/qeWAoRhiCu9ybJUxpotWIb7DNdWGy0oWzxtw4A==;24:hOBTBY4sjDC4KUxhxxOuqN9+n5sGwnObLb+3bH2BTjnwy9wj2MUB7qNlnrQlD3QQGBidcrzNb7RwX458K8qvVMleIcXM+NDoXO5XoOMO3zc= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: hpe.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Apr 2016 20:37:19.6152 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AT5PR84MB0306 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 04/07/2016 02:58 PM, Tejun Heo wrote: > Hello, Waiman. > > On Thu, Apr 07, 2016 at 02:52:33PM -0400, Waiman Long wrote: >> As long as atomic reset is an optional feature that caller can choose at >> init time, I am OK to provide this functionality. I just don't want it to be >> the default because of the performance overhead. > Please take a look at how percpu-ref coordinates global > synchronization. The hot path overhead is one branch which is > extremely easy to predict and shouldn't show up anywhere. If you're > gonna provide reset at all (which btw always kinda baffles me, what's > wrong with taking a snapshot value and taking delta from there?), you > need to make it actually work reliably. > > Thanks. > I would say that because I am lazy, I don't want compute the deltas every time I want to see the effect of running a certain type of workload on the statistics counts. I have use case that I need to track 10 or so statistics counts and monitor their changes after running a job. It is much more convenient to do a reset and see what you get than doing manual subtractions to find out. I had taken a look at percpu-refcount.[ch]. I think the synchronization code is a bit overkill for this purpose as no one really need a very precise statistics counts nor precise atomic reset. I would prefer providing an optional atomic reset feature with slower statistics count update path for the time being. If we come across a use case where we need atomic reset with negligible slowdown, we could then refactor the code to use something similar to what the percpu-refcount code is doing. Cheers, Longman