From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751850AbdI1HtH (ORCPT ); Thu, 28 Sep 2017 03:49:07 -0400 Received: from mail-db5eur01on0112.outbound.protection.outlook.com ([104.47.2.112]:2417 "EHLO EUR01-DB5-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751236AbdI1HtG (ORCPT ); Thu, 28 Sep 2017 03:49:06 -0400 Subject: Re: [PATCH] mm: Make count list_lru_one::nr_items lockless To: Andrew Morton Cc: vdavydov.dev@gmail.com, apolyakov@beget.ru, linux-kernel@vger.kernel.org, linux-mm@kvack.org, aryabinin@virtuozzo.com References: <150583358557.26700.8490036563698102569.stgit@localhost.localdomain> <20170927141530.25286286fb92a2573c4b548f@linux-foundation.org> From: Kirill Tkhai Message-ID: Date: Thu, 28 Sep 2017 10:48:55 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <20170927141530.25286286fb92a2573c4b548f@linux-foundation.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [195.214.232.6] X-ClientProxiedBy: DB6PR1001CA0002.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:4:b7::12) To HE1PR0801MB1339.eurprd08.prod.outlook.com (2603:10a6:3:3a::7) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 2e315fa0-0e2b-4ab7-7425-08d506456250 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001)(2017030254152)(2017052603199)(201703131423075)(201703031133081)(201702281549075);SRVR:HE1PR0801MB1339; X-Microsoft-Exchange-Diagnostics: 1;HE1PR0801MB1339;3:8UEOK8HkNGuxHvbnBdDJkijm8AfNgwisqLAwniqF9SbLGnGUYcr+KIlMYWQh2RYTCjtlNJpHhsl/dVgIuW7bMRQjEWfZQ4pTCy81c4HMmezNcv3o9yAwWN68v83z67nnG9RFw2mKqDcuUL/R/6ZVZBx3B1QMdE6fQ9SmbNNYvOr/4U3MM8udjuwkIWC3mELnxxCLw7r6C809HFf2GZdDOZMt7peFNBqzlMZDXtDMNmss7e9uT8JvGHhmAhUxYPIc;25:OCpBbE3QH8EKIe85/pPzhhei37TYjdvYVIsZbragS6S8E2Nx3/xWmNr/JUVG24KbJTIaSUnu3tCnO1I3r+q8k20Wekd17k/nc6BcqzuUKURyBFB5vW9FdfIArpAmvQWJAr+E6MPizfYUBs5LJuNJUvd3Nvd+07aA9K0zULx64K1EnNKtDdyxEQ3RGO1AZvK41dxqbWButEK6ne5U0vNkeJmufkLWR2fF+EPr96y4B6Am6UXg6jQDRn4UkKyT9u/2iT1JIIs/NbtjoeObzehBG5jyord34S4Z+biPIqDhcrOZHlTzf4YqnGzz0mvFQkR8hg3GCCwC+5XwJtyJfoG+Sw==;31:fhNeB1mt8sRYg14PVzagBa9SVFN5n9znHjG9YofdihN4ICz4u++hcLVglmBJAIGEQNhcV05nEhluJeZcuvNtQY1j2Qc7iRuzrOsJsGtg1Vz+cd3qCooFr+cNYmbdJNjeTEb2W3ReLPJ5bMzt43w+adVNt2izIqqqH9bybc/EDr7UGbmRAkISCrmiSLGhwu7VcCowUiAuGWeKKlXgJl3Bi6YAL9cH1fxQMqd1JGdkthc= X-MS-TrafficTypeDiagnostic: HE1PR0801MB1339: Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ktkhai@virtuozzo.com; X-Microsoft-Exchange-Diagnostics: 1;HE1PR0801MB1339;20:6dlNN/Y2CiL76qCzj+SDFGOTPgqOg42RAAT6/FUnXVOEEyEYMM7f0R9zm1acOhnFHyJTR1ZuEIlfh2tX3jIYOcGoXQGMgA1S61puUE4AG2SH2JHYFHoJ8xyrcYc62V0OWobX7Lfp8k8XFLrGPENrfv0qwMLKzPR7s7TKzg4uWIvBemQ/dXvAlNOi6gmHia/MBkzp+Jm3lvz1KM9pYAsHu2vjm357QLVh94Ks8cIiImrS5VB/iE+Io9ZfV2QjPh6bQnp9gHrwxPXhs9bFRC+rehkLElOLG5AmdcRqD19d01CtsHZk9kcjA97lGMxGCZ4++PTR8WGfVvgOry6UN4HsYyG5D3ipIGBJkLJdc5WXvobXW5ZbMH2j5Lv4cLXNaXFQ4I75a6Gm+ggluYz7R0yn5fK+/h6Gn4RV7mzpHi1epKs=;4:jL9xggHaU5HeqEMjGLwcyL7aq4+ibiLORREkpIkEDl/HlD3RyRbKjzoyXD7jlVF1fLt1NboGwK4tqsI2rUC118iqdJNkQtRQX720SC0qixHj8vQ1wtWtmsYvD/hv73HAUExv1RRpJYuJij9PQNL/fuQCqYSIdk9AYSm9uKBPM1k0lfaViPW2sVc/4+DQHRsz/SuZ0hP5PdwL8cTU/GluC05LseQoMoZOIxaL3nO6Xlo6bTMle8bUU8BnR/crY6CwGpuk6RmTZh8OR1+k8xV5YDVIdOBEBthnoTYER0yeREE= X-Exchange-Antispam-Report-Test: UriScan:(190756311086443); X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(100000703101)(100105400095)(3002001)(6041248)(20161123558100)(20161123555025)(20161123560025)(20161123564025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095);SRVR:HE1PR0801MB1339;BCL:0;PCL:0;RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095);SRVR:HE1PR0801MB1339; X-Forefront-PRVS: 0444EB1997 X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10019020)(6049001)(6009001)(346002)(376002)(24454002)(199003)(189002)(2950100002)(5660300001)(478600001)(305945005)(65826007)(50466002)(2906002)(4326008)(33646002)(189998001)(7736002)(31696002)(25786009)(83506001)(97736004)(6916009)(16526017)(8676002)(81156014)(64126003)(81166006)(86362001)(8936002)(316002)(58126008)(16576012)(6246003)(107886003)(66066001)(6486002)(230700001)(23676002)(65806001)(54356999)(53546010)(50986999)(39060400002)(65956001)(101416001)(76176999)(6666003)(105586002)(36756003)(77096006)(106356001)(68736007)(53936002)(229853002)(6116002)(3846002)(31686004)(47776003);DIR:OUT;SFP:1102;SCL:1;SRVR:HE1PR0801MB1339;H:[172.16.24.149];FPR:;SPF:None;PTR:InfoNoRecords;A:1;MX:1;LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtIRTFQUjA4MDFNQjEzMzk7MjM6b3BlcjVYYkxnblVWRXRwbXNNMUw1TWFC?= =?utf-8?B?RmNYN2ViYldGUWNzSGlsYi9lSTRjMi9ucEttdFlkK2pyaVdXMEhXa0xvQzNX?= =?utf-8?B?UVdaUkV5cjE5WU5oR1J6TDdmNkJEVEFoWlF0eDByTktZamRzRzVWdjZEZmYx?= =?utf-8?B?eUJxZW1pb2V4VXJWaWRweDNMWDJZZnN4VVRQb3VIOTh6OHk5SlpKcDR0Zlgx?= =?utf-8?B?TmxpbTFtTUV1cWdjRGlOZW9PWlN5SjhSMVZ6aVVudG9BU1pIamNyUXJ5NVZ4?= =?utf-8?B?SGkvYWt3UFVpNVd4WnZDMmUxelFTWXNCWkVhZnYva28wYW4zS3RhdnhCenli?= =?utf-8?B?ODhzQVBJUGF4YXNyYndORStIZHlTRjRVWVFiOWpGaXEvWmsxWU8yZWM4QU95?= =?utf-8?B?Y05TNVlZNkw0NURtWE1mbE9VSVhQQmh1d21zdUZqbjZsQUNNZm56TGVzc3g1?= =?utf-8?B?TWRwYU9ZWGVlblpmZkpaVVRNOWtZeGwyeHM3MURKZHpSOCt2Wis1SzVBQ2ly?= =?utf-8?B?eUQ1MWN6V0F6dDlkZVppQjQ4ekxXSEZ1QngxNi90eUNGRGdDUHk1WlBuZGh2?= =?utf-8?B?TzN0OHVEQXlFdW9raVpucWE2SmtJNEJoYWlpLy9GeEg0NFNqeDFjaGVFNkJY?= =?utf-8?B?ZVNFU3RVY3FDZGVIeHNmc1FIMDBJMVNPMFhRbnYwejRoaW00c2ZEN1JBTk1x?= =?utf-8?B?VHlUUnVWdjA1SlN5WVlqTGUzRzNZb2JlSTNDekIrV3lJNkUzYWJZbE04M3Rw?= =?utf-8?B?STZROER1U0pEaUVDT0oyUWpkM3UxOTRNVG5lRHl3c1I0Y0tpZ0o3bVhNUXBi?= =?utf-8?B?R0FmclA5OG4vTXFBeHFla3ZvWmFsS1dkU0pNOHJwMzVPN20rd1kwL1dqSFJY?= =?utf-8?B?YlZGQWk5SEZPUWVrdkxtMkVON1BKTzJSZFRaWEI1RUloUXJOWUtVOWZveEMw?= =?utf-8?B?S1ozOWVqV3JzS2Fsa0ZNa0NXVEJQcU1TSFRTd2JRQnRtR1ZyZ0dCMVZKVjdP?= =?utf-8?B?cUo0OVM5RFJaeGkxTjBDcUlPa0dPT2xaNU5wV0MwUnh4aVA0M2pXYzNCZTA3?= =?utf-8?B?MWJ1OEZxZmtzV25JZnJQMk1hajhCZkJteEcrajVqSWlPOVdxOENTY1F5S3VK?= =?utf-8?B?N1M1dkd3TDhVSTJCQlM5U05vdDFPekVyMVk5ZHNyZ1JRamQwV0h2MEpjUjR1?= =?utf-8?B?a3l6WktHc2tGb2c5cUE0SnIxVEpOdU1yeTUwanJPQmpNMUY0dFhXZFQ1VEJr?= =?utf-8?B?UEdiSkpEMFFiaHJ1bmZ6VlhIdEF5QXBKNCtOOGx2UU85ditKUUVlc3d2Q0Vv?= =?utf-8?B?b0RDazFFc2VwZ3JOZy9NQ1ljVENTMm1iY1lPUUJZdkF0WEFCMzl3czVhdXpw?= =?utf-8?B?RmFoK1BBWkNtQlh0QTJteC85cjZKNkZKck5HUnpqLzVMMHNGZXlWTmgvV0Ry?= =?utf-8?B?K0hCR1ZRRGNGdnhLd3BBblNpNHRPSlUzZURmNFM3NjE3a2UzbzAxLzBrTktv?= =?utf-8?B?amtySnRjK0VMbXlTaDZnc1hDZlRDaXhGSzE1Z2Jzc0wzSDRGZnB2a0g1Z0w0?= =?utf-8?B?YWtYbGozMkFaNkU1VzZoRStUUFRGRVJXMktjSFRFelROWUdINWNPWXNnNnhm?= =?utf-8?B?ZWRpbkpiR29sUDloRmJaeXk2TWg2WTRmdWtpQjRzd0pDTExyWWFSMEJDeCs4?= =?utf-8?B?aTFxamRWMEZNdjY1V1RGeElZL0s3UDR4UkdrMWJmVXpqVy8yVXlPRW5SV3VT?= =?utf-8?B?akcrSEcxR1JvczdZYXhNR01WTkwrdGZDelV1ZDFXcDhweHlyY0xDTFBqWjd3?= =?utf-8?B?MjZJZXEya2VGNm9uTUpqaHlBL1BpOGp6SXNyMEVEbHo4YU41Zz09?= X-Microsoft-Exchange-Diagnostics: 1;HE1PR0801MB1339;6:TqHehN5PagLUMPNb6Hdig5zTy1GPH6XoCSMEGGmluCp92WYiY7dJRqPoon2tvknCJ1te7Y+ZFRJVKtjiWjQKFBxe3H2ik2QgWByw4+VVeXeBmYiMNa8VYee3flTQatirVop2fJWEJNH6PCsThTCtJ3RpaWCqSiDXNSJ72jXXu/t1K0KsueHpQ/ClvBVz+XBxU6aBy228Nia2atTQ+a/LBkGFM3SNB6zB/LtzucgX3yv3r5WXwF7Jm1IgMIxF9VCHsqif75YPmqUA5Ex7/9fGRktfhQJLxgYqr6mYBw6hPZL9aUmbd4yRBAAQfAGVKU/HMPBkEHFdRyzWedDEU5OixQ==;5:UQ6xEJQO+kBvPogvVdWVjaIeBt+uASm9h1G8Q9snVFXxrQaRtE7kX/Z4gchk0yj5FAB/HDybX7FIeNazKNDIxbymmGr9oBAxnfyoKV26LiqLv4ojdNRDfCpyc7l9Vp8Ok4CJrt2guQKIXhplK+uiHQ==;24:JlfAMrUFJ4d31NlKCoSy+vUJQe2ZeKhz3HXkp/E9EVXMHvsGTCiYIz2cV+IiAPcDpJw/0gIlFcQMqfeI6LMwAU/dIyu741xIiyNG924TaZ0=;7:gukWVNWAJsV3VihsximcOQL+3kYljCN50IGun+mr2Yog//fqQxvKNpwYfI9M0E1ohnVaXyJ/5o9o+WeveENqkgu71fnqmVXB66OjFetXFVZC+r7gQRDDE8ohXA7pNlFjsSfKuw0BreK+MLZLhfhLqAcI+ZJZx0/mA8OLbAsfENBx4/336C7qIViOtZvHBtnb6nBmzqT1yr9RzsYCg5zVW5PG+TO2+e5gVMzuuuQLcmM= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1;HE1PR0801MB1339;20:TTcVvbHoma+xA7TyiBKJeAdAXWVEB8k4jvalCiEu4W4dRboscC4niLnXWjZnavqlyjHIrcVdrzGvWG/pJXKAnk5CtRva+Y8olYAqJoHbYEG0TinO2MMkqsYi0mmKZoLlV+zHnMH/foJUW/b1ZWG4+CsaLrenjpoTu43TYbYDG+Y= X-OriginatorOrg: virtuozzo.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Sep 2017 07:49:00.4898 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 0bc7f26d-0264-416e-a6fc-8352af79c58f X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0801MB1339 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 28.09.2017 00:15, Andrew Morton wrote: > On Tue, 19 Sep 2017 18:06:33 +0300 Kirill Tkhai wrote: > >> During the reclaiming slab of a memcg, shrink_slab iterates >> over all registered shrinkers in the system, and tries to count >> and consume objects related to the cgroup. In case of memory >> pressure, this behaves bad: I observe high system time and >> time spent in list_lru_count_one() for many processes on RHEL7 >> kernel (collected via $perf record --call-graph fp -j k -a): >> >> 0,50% nixstatsagent [kernel.vmlinux] [k] _raw_spin_lock [k] _raw_spin_lock >> 0,26% nixstatsagent [kernel.vmlinux] [k] shrink_slab [k] shrink_slab >> 0,23% nixstatsagent [kernel.vmlinux] [k] super_cache_count [k] super_cache_count >> 0,15% nixstatsagent [kernel.vmlinux] [k] __list_lru_count_one.isra.2 [k] _raw_spin_lock >> 0,15% nixstatsagent [kernel.vmlinux] [k] list_lru_count_one [k] __list_lru_count_one.isra.2 >> >> 0,94% mysqld [kernel.vmlinux] [k] _raw_spin_lock [k] _raw_spin_lock >> 0,57% mysqld [kernel.vmlinux] [k] shrink_slab [k] shrink_slab >> 0,51% mysqld [kernel.vmlinux] [k] super_cache_count [k] super_cache_count >> 0,32% mysqld [kernel.vmlinux] [k] __list_lru_count_one.isra.2 [k] _raw_spin_lock >> 0,32% mysqld [kernel.vmlinux] [k] list_lru_count_one [k] __list_lru_count_one.isra.2 >> >> 0,73% sshd [kernel.vmlinux] [k] _raw_spin_lock [k] _raw_spin_lock >> 0,35% sshd [kernel.vmlinux] [k] shrink_slab [k] shrink_slab >> 0,32% sshd [kernel.vmlinux] [k] super_cache_count [k] super_cache_count >> 0,21% sshd [kernel.vmlinux] [k] __list_lru_count_one.isra.2 [k] _raw_spin_lock >> 0,21% sshd [kernel.vmlinux] [k] list_lru_count_one [k] __list_lru_count_one.isra.2 >> >> 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. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg0-f72.google.com (mail-pg0-f72.google.com [74.125.83.72]) by kanga.kvack.org (Postfix) with ESMTP id 377A16B0038 for ; Thu, 28 Sep 2017 03:49:07 -0400 (EDT) Received: by mail-pg0-f72.google.com with SMTP id 188so2376223pgb.3 for ; Thu, 28 Sep 2017 00:49:07 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0094.outbound.protection.outlook.com. [104.47.2.94]) by mx.google.com with ESMTPS id j2si856388pgs.702.2017.09.28.00.49.05 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 28 Sep 2017 00:49:05 -0700 (PDT) Subject: Re: [PATCH] mm: Make count list_lru_one::nr_items lockless References: <150583358557.26700.8490036563698102569.stgit@localhost.localdomain> <20170927141530.25286286fb92a2573c4b548f@linux-foundation.org> From: Kirill Tkhai Message-ID: Date: Thu, 28 Sep 2017 10:48:55 +0300 MIME-Version: 1.0 In-Reply-To: <20170927141530.25286286fb92a2573c4b548f@linux-foundation.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Andrew Morton Cc: vdavydov.dev@gmail.com, apolyakov@beget.ru, linux-kernel@vger.kernel.org, linux-mm@kvack.org, aryabinin@virtuozzo.com On 28.09.2017 00:15, Andrew Morton wrote: > On Tue, 19 Sep 2017 18:06:33 +0300 Kirill Tkhai wrote: > >> During the reclaiming slab of a memcg, shrink_slab iterates >> over all registered shrinkers in the system, and tries to count >> and consume objects related to the cgroup. In case of memory >> pressure, this behaves bad: I observe high system time and >> time spent in list_lru_count_one() for many processes on RHEL7 >> kernel (collected via $perf record --call-graph fp -j k -a): >> >> 0,50% nixstatsagent [kernel.vmlinux] [k] _raw_spin_lock [k] _raw_spin_lock >> 0,26% nixstatsagent [kernel.vmlinux] [k] shrink_slab [k] shrink_slab >> 0,23% nixstatsagent [kernel.vmlinux] [k] super_cache_count [k] super_cache_count >> 0,15% nixstatsagent [kernel.vmlinux] [k] __list_lru_count_one.isra.2 [k] _raw_spin_lock >> 0,15% nixstatsagent [kernel.vmlinux] [k] list_lru_count_one [k] __list_lru_count_one.isra.2 >> >> 0,94% mysqld [kernel.vmlinux] [k] _raw_spin_lock [k] _raw_spin_lock >> 0,57% mysqld [kernel.vmlinux] [k] shrink_slab [k] shrink_slab >> 0,51% mysqld [kernel.vmlinux] [k] super_cache_count [k] super_cache_count >> 0,32% mysqld [kernel.vmlinux] [k] __list_lru_count_one.isra.2 [k] _raw_spin_lock >> 0,32% mysqld [kernel.vmlinux] [k] list_lru_count_one [k] __list_lru_count_one.isra.2 >> >> 0,73% sshd [kernel.vmlinux] [k] _raw_spin_lock [k] _raw_spin_lock >> 0,35% sshd [kernel.vmlinux] [k] shrink_slab [k] shrink_slab >> 0,32% sshd [kernel.vmlinux] [k] super_cache_count [k] super_cache_count >> 0,21% sshd [kernel.vmlinux] [k] __list_lru_count_one.isra.2 [k] _raw_spin_lock >> 0,21% sshd [kernel.vmlinux] [k] list_lru_count_one [k] __list_lru_count_one.isra.2 >> >> 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. -- 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