From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751997AbdK3KhB (ORCPT ); Thu, 30 Nov 2017 05:37:01 -0500 Received: from mail-eopbgr10094.outbound.protection.outlook.com ([40.107.1.94]:34896 "EHLO EUR02-HE1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1750891AbdK3Kg6 (ORCPT ); Thu, 30 Nov 2017 05:36:58 -0500 Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ktkhai@virtuozzo.com; Subject: Re: [PATCH] mm: Make count list_lru_one::nr_items lockless To: Shakeel Butt Cc: Andrew Morton , Vladimir Davydov , apolyakov@beget.ru, LKML , Linux MM , Andrey Ryabinin References: <150583358557.26700.8490036563698102569.stgit@localhost.localdomain> <20170927141530.25286286fb92a2573c4b548f@linux-foundation.org> <20170928140230.a9a0cd44a09eae9441a83bdc@linux-foundation.org> <137a49f9-8286-8bf4-91c5-37b5f6b5a842@virtuozzo.com> From: Kirill Tkhai Message-ID: Date: Thu, 30 Nov 2017 13:36:50 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [195.214.232.6] X-ClientProxiedBy: VI1PR0701CA0044.eurprd07.prod.outlook.com (2603:10a6:800:90::30) To AM5PR0801MB1329.eurprd08.prod.outlook.com (2603:10a6:203:1f::7) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: fef61681-dbe7-491b-c62e-08d537de4672 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(5600026)(4604075)(4534020)(4602075)(7168020)(4627115)(201703031133081)(201702281549075)(2017052603284);SRVR:AM5PR0801MB1329; X-Microsoft-Exchange-Diagnostics: 1;AM5PR0801MB1329;3:Rn4WjktjxskCAjhQoirW1bF8qOEKLiprSK6hlMtpncvmJpWO6jqMpOGqutH2XWXtUK0KEWq2nSdbx5zd6mfnVoat2G1pvFtxC7DzwD5lxHR2KWvFEcgu/2k8T+MaujEdOOT1BONO+KhmrfByMMJCi/XQVkRuFICCsi9deZcq3Go5hVwSiR6WEDUZCCOK0tw/SJHDYND2hbqu5PIx8gppLDNBNMCVYBvAYlWA9kMV9OB5W82VFUtvSZMDm8rIqyy5;25:yT5NDSr6VPj5F4RAvLhDoRja4ThIjRcV23tTSxCxccjk+pRT/0nzEta8rOANK84LfmNRCeyy2/QzdO2g5stVKdCbLDPNy2iW9uWlIoR+EkpGFZ/aA4uj3AVTGqFXdXgQmY1BFTAzqzh36+FPYohulhlVwzUU/7TFSk83uR2pkbsK8G3tb4fMw/PgmRAqN4kci1dZvB27UXrt/mGwbczoKYgpfR3qGW+3je4oSpoiGKwZ2vBVNPWky3L9IUAMeemd1mjJIjkuZB1c247XfonJhhoAx87Q8f3aSGBXugTNFaKuzaxbz//GTodDDJ0rWky3vM7T3p9EZDFcFSLDbETs6g==;31:GmP0omevToWvcXEZFPJ8fFjfFIDOmWuZ5Zv/N04G5rwF4CqhbRbbpVAmL/vvX+kh14Mi61yK5aK/pfZfwjC0EeocF/JzCNUtuoewwJAKB2blqAi8vBhwWNchsglVE4jmPpWf0cBZiKbjbQK0mGxE6ZDkAKX1e+VETPv0t78gvHHg9J3e3+RXWScs7Voz8k7E+4TCPw/rHCbkLzXfG41b9Udy6h1prYi9YAM1R+TxSW0= X-MS-TrafficTypeDiagnostic: AM5PR0801MB1329: X-Microsoft-Exchange-Diagnostics: 1;AM5PR0801MB1329;20:Tw32xJWPe0ZjSxWJL/oI1YH1TQw7cSOsut8uJTroxTyCROptVIp/ejb2I3rBZ+P+Ur/VyiVGfnJ5YHEh6yd6B4HfoiO6qsOEcV6dpxcntQZc+9dNzQB9VTB2TG1MCjNn33Gvfjj2uY/TgPjt1nHlC/+ssIsTD1TOJfuUM6WzJu6cq2WyPS19T6lbsPqpZtK19R3xuLl3dCdmg0cFz4aGdTCQg/0MhZEgy4FC4vbWIrbNQwJVNA+OyfwVcnE6ZxbyQ5jgmZhaJ9uhNaYjLsa90yTVdVHk/+ijxBXR5jKHNz/2eth56HrG94MFY7evMs4EO8pjkbGv8Rw1qwPtQGUCOqY61o/1Pm1cKg12VoOdjwcLP0OdoxZmyq3LLDgkF4Ux0v0v/VhlGWaQtC1VVd/ItWUdiRmwfsShV/doK5xCbcA=;4:HshYyz0r4ZfloLid8S3/RslPZUY8v/4Z36ZXrcpc3mNaVh2a8jrC3DtJ2X/asy/IUOGUNRcuztumIi3WcgFT4YLl6Sj/L776N3F4DXzrC+oKxR4okqf+yu/E+ZK1gPWcnWErdvIDsWXafv2qKoQlYk3AiylML4+lUkTac5vho/Itfxs0byzv3bROzmZPTOF/lb2d5LY9ZjijJ1skjfXbyunfUvh/ITjGy43eE2jpMhsbNag5E1EazxRZAPi8xhEXRaAgOLkmDot9oBnFpP6Yjw== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(3231022)(3002001)(10201501046)(6041248)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123562025)(20161123555025)(20161123564025)(6072148)(201708071742011);SRVR:AM5PR0801MB1329;BCL:0;PCL:0;RULEID:(100000803101)(100110400095);SRVR:AM5PR0801MB1329; X-Forefront-PRVS: 05079D8470 X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10019020)(6049001)(6009001)(366004)(346002)(376002)(24454002)(199003)(189002)(25786009)(229853002)(68736007)(8936002)(105586002)(36756003)(2950100002)(65826007)(31686004)(6916009)(230700001)(64126003)(39060400002)(53546010)(106356001)(3846002)(107886003)(5660300001)(2906002)(33646002)(101416001)(6116002)(6246003)(66066001)(189998001)(77096006)(83506002)(6486002)(47776003)(50466002)(81166006)(81156014)(53936002)(65956001)(16576012)(7736002)(8676002)(65806001)(305945005)(54906003)(4326008)(316002)(23676004)(52116002)(478600001)(97736004)(93886005)(55236003)(86362001)(31696002)(58126008)(16526018)(76176010)(50986010)(2486003)(52146003)(54356010);DIR:OUT;SFP:1102;SCL:1;SRVR:AM5PR0801MB1329;H:[172.16.25.196];FPR:;SPF:None;PTR:InfoNoRecords;A:1;MX:1;LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtBTTVQUjA4MDFNQjEzMjk7MjM6RXUrUnUxeUZZMmJQVzQ2ZnJLQkExQ2xE?= =?utf-8?B?OFc1MnBMdXgveG0yS2d1NWwzM3JicC9hclludy9iQURxYjJsUWVCYTkzdk5y?= =?utf-8?B?ZUVobUVYUHRqWTZJcFpTT0RjRDBITnVHeDdCbHlOQUdPN0VLYm9rdlRUN1Iy?= =?utf-8?B?VjlyZFJsbHpvMlJOMllGT1YwQllSeGI0dXVNcXBxY1U3T1JUTjFyMnpJK1hB?= =?utf-8?B?Q09LcFJYYVNWZTdmMmdmVGtIUVdhdk0veDBNeXp5UDZxb2tnUU1XRG1kdTFU?= =?utf-8?B?Ti92UzlrUkNGQUZEV3IvVFVhUWRKbkpzLzVvajRETXBsMHVVVWc4aGlpWmpT?= =?utf-8?B?aWZLNVBvNExTYjV0QzNTMWh1MVcxUEZINVJ1a3NjVldBYW9reTU4Q2s5bi9Q?= =?utf-8?B?WWlNOGhBbFU0TU96bEhlVVh6eEllS0pxZlVqSEQ5OUtpSk9YVGp1VHQ1VkNY?= =?utf-8?B?ckxoeHB6WDY3bCt3OHNvTkdtdENCZjREc0psUXY4NldIYkFRTVdjTUY0a1lY?= =?utf-8?B?bFRIN2J2WnNoRlhaUFBOejN3engrVzNic0ZsMXRGTmpjUWRFUnh5eVpSRm9k?= =?utf-8?B?RFJxeVFBM3hLcXZRMDJLQU9nNFU0RFRsNHVOMzVwVlB2RHVoU0h6TjBJTm1M?= =?utf-8?B?RHZjWFFuYXE3VmcyM1IvZmNHMFdmQ0VtSGlneVhLMDNUSC9zNVNyV3ZtSUtM?= =?utf-8?B?S0hmUm9ieDBBVGlrTVdOUkZSK3Y3aC90THpPWitBa0Q5K1lHakRoTXkyUEFp?= =?utf-8?B?SWp2Yld6NjJWUU1qSENGTmNJN3dlTmxFNnFDeXhydE5nZmVzOWVGdEcyeWdW?= =?utf-8?B?a2hJckkvMFIzSklZZDJENG1xMkNCK3Y2VDBUa2F2SzBMWWdwamZNWStueHhW?= =?utf-8?B?WXlqNzFKSGticXdrVyt3UDkxVzZBbmJITHNrd2w5Y28yTkIzRjRMVVhpZkZH?= =?utf-8?B?akd5Q0F0WEM5aGFyUy9MbHdpdENmQkYvbFpFSkFpU3dUN2Rwc0ZYMFNETldW?= =?utf-8?B?bTlxTWtUb3JRYUdHWlRMZ3hQYjhWQkZKQXM2ZnBEbHl5b2RqWk9GeHk2K20v?= =?utf-8?B?T0dHbXNUcnB5UlVBUzdSNzJCVVc4QkdOMzArK1JFMWR4SzlkWDl4aXZUZXNj?= =?utf-8?B?Nnc4bHRwMjh0aVBETFYyK2FYaXA3aWZvY1hNaU9OOGhCZXlhV2xZQnNON1Rr?= =?utf-8?B?RHJwWnI3L1pzei9mSEJ6ZXc3bS9JbnNLSk9CWVZ1VVVqNHB0K3hBZVJ3S1FE?= =?utf-8?B?dGEvTUZWQjI2N1lzUzdLQkxURytySnozS3VFS0t4cWs2SmpmbTJZK2lNV0I3?= =?utf-8?B?VysyT2MrMHBZNTRxbE5ISDZwczllTmwvSWFONVZqOWNlZmhqMmhHbjBkRXNx?= =?utf-8?B?V2xyb1hJQ3oxOEJOaTc5S1hMZ0RnN2JyYjY3Rk00VmNmSFprMmlGNmtWbGJZ?= =?utf-8?B?cXA4UlhKaThISDliV003QmlGdlBTUG5lSHpmQ2hGZ2k1N2VLTWJnblpnQXlM?= =?utf-8?B?cVVJTHpXWHl1MGNEVGhGSEgxR2RZMEZEOVNBNkMybkZuZHEzc2Z1ZmRFdnZy?= =?utf-8?B?TDVCTHdtS204N2ljOHIrRUlvOEpuN3F6bkNkY1hqdWd6ZDJodWp0U3cxa2R3?= =?utf-8?B?N1F1SkVRbmFYd2R2dEZ6Mzc1QjhjMUw3MmxWTWF3U0FXcUVqbzJpa1l2bzVy?= =?utf-8?B?RFIxNW5FamwzZFpDL2NZWlRrN25BZ2RxNzlFaGRHMVZaT3VCajhQTGM3OUlz?= =?utf-8?B?YUdJMkduOHVCRGlkelluc3BMUzhOR0sweCtKanR0WUJLNXgrYmdrQUdaWmd2?= =?utf-8?B?amVPWm1jZ1lTb2I1YWtDaXpaODJIZ0h4MGx1UGF0TEJNbGlGcUJyKzRTemE2?= =?utf-8?B?RmxXZnZWWDZCcUYvc0huaU5uRkxzcHlTK2hGc2hDR1NMMDliS1hhb0t1Uk5j?= =?utf-8?B?dCsyS3VTUUdNd3NENGFlSzBiZnVGMUVLTTFodjFzTXN5T3FxcG4yOW9icGRl?= =?utf-8?B?a2JvUnV5L0g0VE10YkxnYVNrZXlZN1hIdjJ1NXlRPT0=?= X-Microsoft-Exchange-Diagnostics: 1;AM5PR0801MB1329;6:nld/h387YbkXE1cxVOkfMZgmCyxifhIWJpx/K0Qd83/vlJgszHGYTcyrgOG/7KHt7jDIJRO50UQEL0CxpHzrdUggejYc4CHv7LbmbkLyq9fXDMQFO8FizwhzIDuxpCNKmdV4s/2ifiiQevDvs4NMnwHzcGKxOv6AYLAtyHeXE2QZlsqMSOaVxdTz4jXLmaV4XZob0w3M8LcpBslNyKiLOrv+MNW3scvb4ijcoEk2I80c39Xiwswy2TCjqyb8ZtmM3cZZtvU/T+pMqw/STZqfGUXzeSdnnu+WOoPoPYLKTjg1TTOeSzFLHn4W5tXP/jftEMQdbMM0Ibyha5jhfRh0AbUGceVWgCEMpjGgO6yFxBU=;5:ABHIJ+N02L1WlO1d5cRa9VzzC2GGkKG1hpI//MICyDaRFnlfhEkr/u9izrqY2ABJGkCf50XYAQHfkzR3ZkKVRHjbhA2kCxHpQhtyseLK1b+TvYUSSTI4anhJyDegdQJlFTPPdeVAnX5KnrYU+jTi2sQlR5XJPTZllnp7iFTAxyk=;24:5HJVt4T8O4U8LiPAUJH3dvzaLHdFPo2UJvBuAG9UgGOO1nBUSSVu3S6d5RDRkZoGYtAyrgHsKSvrSz5scnukq7JoUKM8RY/7WMWtpJbuebE=;7:YskC5ApRJGYQbDnmb711K9F9vHN7vqlLsDjWkzB+/5jYpxmsNbOrwVkGzJfeRBjBC5bmx5qG0SxLH35+LMXhdwJoQAYswO2P2+eNypj5ZsZR1n53Pk3aWjXW2o4NLTtoXRG/KkwX52IaZf0hh2jJTLYXBNACaLVqOwI96YYdEG4ep3qhfmZjtCwmGE+bg7tCxsUw6rY67DX92UUjMLg28rw2QT6bq5zuA0yh8K20PD0PpaxHBjPUP+ABCogzBk7q SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1;AM5PR0801MB1329;20:4oYvazuytx1qU6vFXLtDkH/1wgWKcltbIcdqZ7nQOPOi9avwPFY5ArOHPn0TcLqWTZHcRanqIc/Z+MdGxAajzPYLzVpRXmbCTMilTseLucE3Cvq9m93DMbQAPhDQ0QsWAtKO8cbfbqkT53CRvtHoyDdo7rOGA3WjZq6Er+TxPJo= X-OriginatorOrg: virtuozzo.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Nov 2017 10:36:53.9174 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: fef61681-dbe7-491b-c62e-08d537de4672 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 0bc7f26d-0264-416e-a6fc-8352af79c58f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0801MB1329 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 30.11.2017 03:27, Shakeel Butt wrote: > On Fri, Sep 29, 2017 at 1:15 AM, Kirill Tkhai wrote: >> On 29.09.2017 00:02, Andrew Morton wrote: >>> On Thu, 28 Sep 2017 10:48:55 +0300 Kirill Tkhai wrote: >>> >>>>>> This patch aims to make super_cache_count() (and other functions, >>>>>> which count LRU nr_items) more effective. >>>>>> It allows list_lru_node::memcg_lrus to be RCU-accessed, and makes >>>>>> __list_lru_count_one() count nr_items lockless to minimize >>>>>> overhead introduced by locking operation, and to make parallel >>>>>> reclaims more scalable. >>>>> >>>>> And... what were the effects of the patch? Did you not run the same >>>>> performance tests after applying it? >>>> >>>> I've just detected the such high usage of shrink slab on production node. It's rather >>>> difficult to make it use another kernel, than it uses, only kpatches are possible. >>>> So, I haven't estimated how it acts on node's performance. >>>> On test node I see, that the patch obviously removes raw_spin_lock from perf profile. >>>> So, it's a little bit untested in this way. >>> >>> Well that's a problem. The patch increases list_lru.o text size by a >>> lot (4800->5696) which will have a cost. And we don't have proof that >>> any benefit is worth that cost. It shouldn't be too hard to cook up a >>> synthetic test to trigger memcg slab reclaim and then run a >>> before-n-after benchmark? >> >> Ok, then, please, ignore this for a while, I'll try to do it a little bit later. >> > > I rebased this patch on linus tree (replacing kfree_rcu with call_rcu > as there is no kvfree_rcu) and did some experiments. I think the patch > is worth to be included. > > Setup: running a fork-bomb in a memcg of 200MiB on a 8GiB and 4 vcpu > VM and recording the trace with 'perf record -g -a'. > > The trace without the patch: > > + 34.19% fb.sh [kernel.kallsyms] [k] queued_spin_lock_slowpath > + 30.77% fb.sh [kernel.kallsyms] [k] _raw_spin_lock > + 3.53% fb.sh [kernel.kallsyms] [k] list_lru_count_one > + 2.26% fb.sh [kernel.kallsyms] [k] super_cache_count > + 1.68% fb.sh [kernel.kallsyms] [k] shrink_slab > + 0.59% fb.sh [kernel.kallsyms] [k] down_read_trylock > + 0.48% fb.sh [kernel.kallsyms] [k] _raw_spin_unlock_irqrestore > + 0.38% fb.sh [kernel.kallsyms] [k] shrink_node_memcg > + 0.32% fb.sh [kernel.kallsyms] [k] queue_work_on > + 0.26% fb.sh [kernel.kallsyms] [k] count_shadow_nodes > > With the patch: > > + 0.16% swapper [kernel.kallsyms] [k] default_idle > + 0.13% oom_reaper [kernel.kallsyms] [k] mutex_spin_on_owner > + 0.05% perf [kernel.kallsyms] [k] copy_user_generic_string > + 0.05% init.real [kernel.kallsyms] [k] wait_consider_task > + 0.05% kworker/0:0 [kernel.kallsyms] [k] finish_task_switch > + 0.04% kworker/2:1 [kernel.kallsyms] [k] finish_task_switch > + 0.04% kworker/3:1 [kernel.kallsyms] [k] finish_task_switch > + 0.04% kworker/1:0 [kernel.kallsyms] [k] finish_task_switch > + 0.03% binary [kernel.kallsyms] [k] copy_page > > > Kirill, can you resend your patch with this info or do you want me > send the rebased patch? Shakeel, thanks you for the testing! I'll resend the patch as "v2". From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io0-f200.google.com (mail-io0-f200.google.com [209.85.223.200]) by kanga.kvack.org (Postfix) with ESMTP id C13C66B0038 for ; Thu, 30 Nov 2017 05:36:59 -0500 (EST) Received: by mail-io0-f200.google.com with SMTP id w191so5421621iof.11 for ; Thu, 30 Nov 2017 02:36:59 -0800 (PST) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50129.outbound.protection.outlook.com. [40.107.5.129]) by mx.google.com with ESMTPS id l187si3307220itb.54.2017.11.30.02.36.57 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 30 Nov 2017 02:36:57 -0800 (PST) Subject: Re: [PATCH] mm: Make count list_lru_one::nr_items lockless References: <150583358557.26700.8490036563698102569.stgit@localhost.localdomain> <20170927141530.25286286fb92a2573c4b548f@linux-foundation.org> <20170928140230.a9a0cd44a09eae9441a83bdc@linux-foundation.org> <137a49f9-8286-8bf4-91c5-37b5f6b5a842@virtuozzo.com> From: Kirill Tkhai Message-ID: Date: Thu, 30 Nov 2017 13:36:50 +0300 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Shakeel Butt Cc: Andrew Morton , Vladimir Davydov , apolyakov@beget.ru, LKML , Linux MM , Andrey Ryabinin On 30.11.2017 03:27, Shakeel Butt wrote: > On Fri, Sep 29, 2017 at 1:15 AM, Kirill Tkhai wrote: >> On 29.09.2017 00:02, Andrew Morton wrote: >>> On Thu, 28 Sep 2017 10:48:55 +0300 Kirill Tkhai wrote: >>> >>>>>> This patch aims to make super_cache_count() (and other functions, >>>>>> which count LRU nr_items) more effective. >>>>>> It allows list_lru_node::memcg_lrus to be RCU-accessed, and makes >>>>>> __list_lru_count_one() count nr_items lockless to minimize >>>>>> overhead introduced by locking operation, and to make parallel >>>>>> reclaims more scalable. >>>>> >>>>> And... what were the effects of the patch? Did you not run the same >>>>> performance tests after applying it? >>>> >>>> I've just detected the such high usage of shrink slab on production node. It's rather >>>> difficult to make it use another kernel, than it uses, only kpatches are possible. >>>> So, I haven't estimated how it acts on node's performance. >>>> On test node I see, that the patch obviously removes raw_spin_lock from perf profile. >>>> So, it's a little bit untested in this way. >>> >>> Well that's a problem. The patch increases list_lru.o text size by a >>> lot (4800->5696) which will have a cost. And we don't have proof that >>> any benefit is worth that cost. It shouldn't be too hard to cook up a >>> synthetic test to trigger memcg slab reclaim and then run a >>> before-n-after benchmark? >> >> Ok, then, please, ignore this for a while, I'll try to do it a little bit later. >> > > I rebased this patch on linus tree (replacing kfree_rcu with call_rcu > as there is no kvfree_rcu) and did some experiments. I think the patch > is worth to be included. > > Setup: running a fork-bomb in a memcg of 200MiB on a 8GiB and 4 vcpu > VM and recording the trace with 'perf record -g -a'. > > The trace without the patch: > > + 34.19% fb.sh [kernel.kallsyms] [k] queued_spin_lock_slowpath > + 30.77% fb.sh [kernel.kallsyms] [k] _raw_spin_lock > + 3.53% fb.sh [kernel.kallsyms] [k] list_lru_count_one > + 2.26% fb.sh [kernel.kallsyms] [k] super_cache_count > + 1.68% fb.sh [kernel.kallsyms] [k] shrink_slab > + 0.59% fb.sh [kernel.kallsyms] [k] down_read_trylock > + 0.48% fb.sh [kernel.kallsyms] [k] _raw_spin_unlock_irqrestore > + 0.38% fb.sh [kernel.kallsyms] [k] shrink_node_memcg > + 0.32% fb.sh [kernel.kallsyms] [k] queue_work_on > + 0.26% fb.sh [kernel.kallsyms] [k] count_shadow_nodes > > With the patch: > > + 0.16% swapper [kernel.kallsyms] [k] default_idle > + 0.13% oom_reaper [kernel.kallsyms] [k] mutex_spin_on_owner > + 0.05% perf [kernel.kallsyms] [k] copy_user_generic_string > + 0.05% init.real [kernel.kallsyms] [k] wait_consider_task > + 0.05% kworker/0:0 [kernel.kallsyms] [k] finish_task_switch > + 0.04% kworker/2:1 [kernel.kallsyms] [k] finish_task_switch > + 0.04% kworker/3:1 [kernel.kallsyms] [k] finish_task_switch > + 0.04% kworker/1:0 [kernel.kallsyms] [k] finish_task_switch > + 0.03% binary [kernel.kallsyms] [k] copy_page > > > Kirill, can you resend your patch with this info or do you want me > send the rebased patch? Shakeel, thanks you for the testing! I'll resend the patch as "v2". -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org