From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933407AbdDEKbF (ORCPT ); Wed, 5 Apr 2017 06:31:05 -0400 Received: from mail-db5eur01on0094.outbound.protection.outlook.com ([104.47.2.94]:22849 "EHLO EUR01-DB5-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S932269AbdDEKaD (ORCPT ); Wed, 5 Apr 2017 06:30:03 -0400 Authentication-Results: vger.kernel.org; dkim=none (message not signed) header.d=none;vger.kernel.org; dmarc=none action=none header.from=virtuozzo.com; Subject: Re: [PATCH 1/4] mm/vmalloc: allow to call vfree() in atomic context To: Michal Hocko References: <20170330102719.13119-1-aryabinin@virtuozzo.com> <2cfc601e-3093-143e-b93d-402f330a748a@vmware.com> <20170404094148.GJ15132@dhcp22.suse.cz> CC: Thomas Hellstrom , , , , , , , , , , , , , , From: Andrey Ryabinin Message-ID: Date: Wed, 5 Apr 2017 13:31:23 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170404094148.GJ15132@dhcp22.suse.cz> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-Originating-IP: [195.214.232.6] X-ClientProxiedBy: HE1PR09CA0056.eurprd09.prod.outlook.com (2603:10a6:7:3c::24) To AM4PR0801MB2722.eurprd08.prod.outlook.com (2603:10a6:200:14::24) X-MS-Office365-Filtering-Correlation-Id: 946ed921-0e1c-4ac0-7f4c-08d47c0eb661 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001)(201703131423075)(201703031133081);SRVR:AM4PR0801MB2722; X-Microsoft-Exchange-Diagnostics: 1;AM4PR0801MB2722;3:F2s1oju0qEPa33+94EsrhX0lrfhOXZsXDWjdaviXrxiLfdZ3OpPkCjqZiQ24N7QuGJ8zM+d0ypkpe6prVrtrXyx8BeRuB4AsowBZ7uN/wNDOYwYjDDb8VpBgxAIgugXk6CGq1q8aYi4h/4XEEfIFBJrQKu/xGKudLxR+AtpgM3OgQxLV+f6Fh2T3VI5LWGwfqaA6aQ/h5yc/yJFSysm5sw+U+0ESg9bcwDssWEw+qwJScwHpKdgWTU23XMGOnKzRt95Ydc+xGxMATaFTnCkAga0HOK+/+fhkBdjfWha2aqOxypeEZJlkwZbQNQtmC1jiDUosX0EaiLFXSwPt8otw+A==;25:CYXDYAWjYZSaLgkMlDPxXn+XS679Q2vtasSRejNFSGcnpgRQrD7Oxg1/xwKCZCYUdlnSTybXLstSqRBRkLFjEgXz3AAm5THVXBPAKvw9gs2ma6bNeFyR3AgaXzubQWtZ3iwudWlm6rVuF5U/0o7SM1zhxj7xob/HJMVyTT99KCMrUxf4r3XHnyJaLn+b6+oPnrpc7eOMf5WPzCuifEQuYJatPnNEX9Pqq4dwRUnABpvK8c3irjGX2gzXgFez04el+61gYVOZzSfD47AgZq1V5zW04zLKaP8Cs/7945VdCrS7KR2OnD8XNqzM1hLMc++iCRom4ruekDKcgR59AtN+BLdvPEGP8QPH6bfPllU+DiUcHZrWQ3E9EtlO8mHzXf66DdqWtHx1mP1gXznB5uPrPp/qFMeTmiDIX4PTaKgZuE0suH1/qQpGsffdj7WG11dUJSTCX60w5FGPYtwiSzKSvQ== X-Microsoft-Exchange-Diagnostics: 1;AM4PR0801MB2722;31:Za0lOGAmrIS7GhMO12/yPFCXic227OauBNdovJunegZpODrYwFBJr3r4ACy8lgnFTy50yCdWxqaq7gFMzKjrfZ5Gb2SSMdt5fEcw0XZCH18HXp4AscRI+HHUc7xFOg2b8n+JUgM8AMIlAJ0tqIENLAL3cllpskFe502H6dk8mmwGzyZfHPX3K/iBIe/jY6bLSEk7EbrkOR8eHf/pAtCZ0F3o7X9kOKQ27xeqMbz34+OYy3MIMha7D81XW8Z56x3/gbSmq3ICWr+Yg3yxnOen2w==;20:dNPH6V8tHF9grDM5cEKq2FSowUsvnr1JuECWzaZ5nfLqNohWaMniqsREt08BaL6ixzgspK+XM0fB2hLstAQPkxo/SuZZ+zu/b9ImoYmIGgR00RyDZTjtE4S0Nml2lHHZy01V+ewsw7omIo/w26n+sPHgITHp+GnGvHh2uMlwpovo7Z+sDd/HBNr3uo8JAt3wo1TVz/DANSR0UbC8LS2LhoAxTsz7CjJuv9nTJ0Zrg6JON94sAQEqJmHquYFtpW+ber7pWLFEgPfFfc7vhCJvqLrMpdwdjtsIsB3DrpvUYGWqQ/VoClNoBD5YsZJY9S2POry1oh4pNMbEGRS+6qdlAEgegGfh3EAUPOgZpfv9rxetAWnZZCrrkB4BHWdhNl/EaxsL/7weV1bXMxyKMwimpnmx1w4y0J577532aygdyeI= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(10201501046)(6041248)(20161123562025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(20161123564025)(20161123555025)(6072148);SRVR:AM4PR0801MB2722;BCL:0;PCL:0;RULEID:;SRVR:AM4PR0801MB2722; X-Microsoft-Exchange-Diagnostics: 1;AM4PR0801MB2722;4:jjNH0Cyw6Ip9EsxajOvAFhmtv8aPslYaL+lRBBVsh8L5S44IXV7LhqtP1SLEn5kdk23dfbBuIgAeAZebxeMFcqEhJC3uH2lyoYTT8wDGq7mTy06RJlHVsR46V59BV7gK1howQxAh0o8wDQDCHcRvioRpGhFoMW/Sm6uwGF04eQaCxv3hCo2GQn6MH/IwGaG7AxJSvaKfcPBpBt4G0srnHvgDDbmnB8tSiykWaTD6NRi0SoiL8KiWfsYCDm7pRSjr2MWJ9oSrohL7FToXwt/bhoktfqPTLYEawr0Ob4EyBqMqHbqhNOus4tBDtEGze7ABUQVbs5HXUfberOYTfQvRyigKjgccGJKVC9ONM493u0Os+Dh0hMiFLuuAeMSZMtaI3oNVHwKrvXxPWZ/ucrrU66gqsq7ayzpl/YVFaSmlCHHfaaQCMhvGm4J1VxoZrE58h77rbz6dkx8b2z4mdZKkW5G+/PIa6arlUiD/rNHv5A2j+Mximo0nPk+Wu0OANuBYO+H/9JsT9KrPaSnml1R5CssfYHtHIlcn00RvLrqiYHGSN8aKO3F902Lx1B5iFmob2jnf31q9Tei0GNIWez0FJ7VIovPsZzQm1QkXTR+vdEmuDcaKjXnpmScjmhFCuu+H0ImcyYdUd9zV9afMAOd7i+TTjI+9JL0bp3cYCaXAOm2SYNZwa7wEaaTCCr9E08A8PE74UwzctURsmBv8nvSTnA== X-Forefront-PRVS: 0268246AE7 X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10019020)(4630300001)(6049001)(6009001)(39410400002)(39450400003)(39400400002)(377454003)(377424004)(24454002)(6916009)(4326008)(65826007)(53936002)(42186005)(2950100002)(6666003)(54906002)(6486002)(86362001)(575784001)(93886004)(64126003)(65956001)(65806001)(66066001)(50466002)(31696002)(33646002)(54356999)(76176999)(50986999)(77096006)(38730400002)(36756003)(229853002)(81166006)(8676002)(230700001)(7736002)(305945005)(7416002)(25786009)(53546009)(47776003)(6116002)(189998001)(3846002)(23746002)(6246003)(110136004)(4001350100001);DIR:OUT;SFP:1102;SCL:1;SRVR:AM4PR0801MB2722;H:[172.16.25.12];FPR:;SPF:None;MLV:sfv;LANG:en; X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1;AM4PR0801MB2722;23:5ZWlq37YebXXqI/ex8FydPz/B2w5OuH7UL+?= =?Windows-1252?Q?rTRvlAKT2TS+kFsRaYKrgdNf9AcysScrR5T4tgi5sBtp61QvuIxS1XNR?= =?Windows-1252?Q?T1DOo0j90evnzV2xHG4bE8tegRlvw4ZLGqGOa66dwFJeHhvlXjLvBfwB?= =?Windows-1252?Q?p015Mdj9Fp6l5e4SJw9enVioUgJ4Gd6i9QzEbzxtfHc5Uj8mR73JThqy?= =?Windows-1252?Q?U/ZbHmfPOHrvLObWDyyayg4ThbMcGNDs4tlO9ab+0Ir3ImIQ6vwfqDeu?= =?Windows-1252?Q?kdVSWyMP/GrV7aF7MCqD4n3DhaN+RxRFGdl/b1CbyH9NHxkB4xFnD+74?= =?Windows-1252?Q?cGGWZrSDvZcynJR//hw7RJ6WS9RCCRhfSZYclfSDVpTCAJ47YFC2rXla?= =?Windows-1252?Q?xzTPcRmh/xUDZYTDGUT2/TYlPPaKfw9rmFmmITQOsz03Y8sn5VF6XtQX?= =?Windows-1252?Q?bWQrZH3fBTpMCUmqcvM/dt/Xrrsex2J7JOTjfPV3sE1mP9pMONZKbGfB?= =?Windows-1252?Q?Qxg5tuo7JvXn7O5VyIo5vHabiQoU/2tfNYCNyg++O/R/AjU5njxUwFGP?= =?Windows-1252?Q?jmEk5XmhQrNesR3dEo3oJJ1l5wzg2zi/dOsj749kqhtDeP2y6zLEx8SU?= =?Windows-1252?Q?giHqpv3ePSIo+vScbhL3O8dIGePwl20wayWQig+9+3azGql2e+D5cwgG?= =?Windows-1252?Q?kvBRXDptjzfRTxCSGhgsoWWA5htK0rj+OrRqHPyABl429BBm3B1iNV82?= =?Windows-1252?Q?W7s+84zcteYUzRXCUtDWqUi5o9q2GdG6qAof292KRZFccwCNIoOvELQc?= =?Windows-1252?Q?zMWyvTkC9y1eL9l2suHtKVGOdz7+MK9NX2jEL5di941Q8HwqjYEyp6ik?= =?Windows-1252?Q?B3N7KGlmwPSRTS9YHwyMi5oTA9hEI0uvkUJ/7Zf/6sQQW3ZIxCNCjuzR?= =?Windows-1252?Q?6ZfvYS9qZoogsPTZEU7gX1EKpGFqWOONmk8GsQlHB1o3EstaLYb2Zhun?= =?Windows-1252?Q?RoJYcaC0i7M8tKI0bww2N0Ig4rizyBvF2Cu79VPEVay464oeMDpJyN8Q?= =?Windows-1252?Q?fIrhnmvbEbB77a4sB6xNFfDwkP2owzKK2IT2hvv4S2Aa06BFTILWt0zh?= =?Windows-1252?Q?0q1l4NJAYINdkp2U3fyEiMfs2LixTFHPjyKM2pJ1cIa/Aju8lR80QivH?= =?Windows-1252?Q?R5o7qpHrelo2bxU/pbc4qobyJTL4yXXWKnjl+cloz8soj826TDTwfsum?= =?Windows-1252?Q?K766k/T24RyMMXAhVxXETryANSmL0TKcFQTwe2ug4i2Ah7ddQ7iKW/03?= =?Windows-1252?Q?8ih34CHOitfm5DWOgJfAeJl7xdNos5hWjPj0DrUboPLmwBGg=3D?= X-Microsoft-Exchange-Diagnostics: 1;AM4PR0801MB2722;6:BhktxFexVormp97Y3JFjjcCU8LrDy4iPiqp/WLwpT9McnaGf1pdvOVJwCY6x0Z/CVaQ4MqHHixBlYj2VZTBWjjPLSw3IYYPiem/qof9UQ05kHce0tatUTqwWZUafLnAZK0kwJ+ufOZ5IxAskaOZvRZFW9y3u3h1P34DP5QUKPYW35RJrlOdo9BXu2m84nd0VS0yfcBgyz1gPE/l9h+umrCucko12PXreiwYUBQAIg8vlN4o2ww1MTgtDgPVdk3ckfm90WhRNrslLz3mgVp3K7tw3M8CbOStxpqEML2qzdyEjvy4htQXJH9khKaIognK8591GfqyFEZ6eu/itg6NYtMQC3Zw5wvOGmGRWra1pjmfLxlmGnqEYMdpK+1D0MnePDZoChAoludqMMKucnwc3pQ==;5:CGaTTbI8QMfFt2w8208TVtwkUxaivNX9+gM+8FvXvaH2G5AGjhrkvBWgsPWtHaFqOBYlF1+FInItTORZfbxBcvOEeaVqOsxdhkOwia2yxWh0ytwglly9GgUiZgQhMbi80i6DWndqnqcrR7hiiF3Gow==;24:2QlVD7oTS1ARDE319drTuXj3JbXeUXgvI4e0ZKwpsPEDTbcKkYhuEodu09cA31mJOf9WPQg+MKeOBdKu6OJZbEeegiCmLhap8mSOSoesT2I= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1;AM4PR0801MB2722;7:tctiobMLbw3OUfDIB9e3oN7IBntGvlUHN79H+wS991LwiW8oDqO9heZ4Moy8DYe0SHN039Zh/Y10bT44Qjy6FpPoMySPZsKZsu6atyMfd0kV+K1bAVmUpnZ1e4OhO9HYwr++B03gyEGjNu1ygjuu+UK7yjWqxXssDWaI4c5EdaIAXVaQNMpt0YaxZ5DSAlIlHCCD385JsI3YK4ZbZc1bhO39tBzdvsU+guo2pwLA2tKtwYpMN7r8DGRiLO/UzLJ1hG7cXYh7c8++vPPP0X9kUAQqAH8016n/fVU1jNYvCbvPyRNLsaR3jsza/O3fODZCww1J+fhscYJbsIcZbiiC2w==;20:4i9GIxPoU8YDodns8ZqW0TUpvr+uudlxvMwpXagCCqUC4qTP2p534yrmLR9v/7kDGCTAiQquvr+osx2hLyF90ymn3cRLtlx3M/fwIP7G3ZzBa5oiS7ujsgEjRy8fGjvr63bAbstfYWO3+50XKo/GTYok08dc6D6/ObcytNX2uw0= X-OriginatorOrg: virtuozzo.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Apr 2017 10:29:58.3020 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0801MB2722 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 04/04/2017 12:41 PM, Michal Hocko wrote: > On Thu 30-03-17 17:48:39, Andrey Ryabinin wrote: >> From: Andrey Ryabinin >> Subject: mm/vmalloc: allow to call vfree() in atomic context fix >> >> Don't spawn worker if we already purging. >> >> Signed-off-by: Andrey Ryabinin > > I would rather put this into a separate patch. Ideally with some numners > as this is an optimization... > It's quite simple optimization and don't think that this deserves to be a separate patch. But I did some measurements though. With enabled VMAP_STACK=y and NR_CACHED_STACK changed to 0 running fork() 100000 times gives this: With optimization: ~ # grep try_purge /proc/kallsyms ffffffff811d0dd0 t try_purge_vmap_area_lazy ~ # perf stat --repeat 10 -ae workqueue:workqueue_queue_work --filter 'function == 0xffffffff811d0dd0' ./fork Performance counter stats for 'system wide' (10 runs): 15 workqueue:workqueue_queue_work ( +- 0.88% ) 1.615368474 seconds time elapsed ( +- 0.41% ) Without optimization: ~ # grep try_purge /proc/kallsyms ffffffff811d0dd0 t try_purge_vmap_area_lazy ~ # perf stat --repeat 10 -ae workqueue:workqueue_queue_work --filter 'function == 0xffffffff811d0dd0' ./fork Performance counter stats for 'system wide' (10 runs): 30 workqueue:workqueue_queue_work ( +- 1.31% ) 1.613231060 seconds time elapsed ( +- 0.38% ) So there is no measurable difference on the test itself, but we queue twice more jobs without this optimization. It should decrease load of kworkers. >> --- >> mm/vmalloc.c | 3 ++- >> 1 file changed, 2 insertions(+), 1 deletion(-) >> >> diff --git a/mm/vmalloc.c b/mm/vmalloc.c >> index ea1b4ab..88168b8 100644 >> --- a/mm/vmalloc.c >> +++ b/mm/vmalloc.c >> @@ -737,7 +737,8 @@ static void free_vmap_area_noflush(struct vmap_area *va) >> /* After this point, we may free va at any time */ >> llist_add(&va->purge_list, &vmap_purge_list); >> >> - if (unlikely(nr_lazy > lazy_max_pages())) >> + if (unlikely(nr_lazy > lazy_max_pages()) && >> + !mutex_is_locked(&vmap_purge_lock)) >> schedule_work(&purge_vmap_work); >> } >> >> -- >> 2.10.2 >> > From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Subject: Re: [PATCH 1/4] mm/vmalloc: allow to call vfree() in atomic context To: Michal Hocko References: <20170330102719.13119-1-aryabinin@virtuozzo.com> <2cfc601e-3093-143e-b93d-402f330a748a@vmware.com> <20170404094148.GJ15132@dhcp22.suse.cz> CC: Thomas Hellstrom , , , , , , , , , , , , , , From: Andrey Ryabinin Message-ID: Date: Wed, 5 Apr 2017 13:31:23 +0300 MIME-Version: 1.0 In-Reply-To: <20170404094148.GJ15132@dhcp22.suse.cz> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: On 04/04/2017 12:41 PM, Michal Hocko wrote: > On Thu 30-03-17 17:48:39, Andrey Ryabinin wrote: >> From: Andrey Ryabinin >> Subject: mm/vmalloc: allow to call vfree() in atomic context fix >> >> Don't spawn worker if we already purging. >> >> Signed-off-by: Andrey Ryabinin > > I would rather put this into a separate patch. Ideally with some numners > as this is an optimization... > It's quite simple optimization and don't think that this deserves to be a separate patch. But I did some measurements though. With enabled VMAP_STACK=y and NR_CACHED_STACK changed to 0 running fork() 100000 times gives this: With optimization: ~ # grep try_purge /proc/kallsyms ffffffff811d0dd0 t try_purge_vmap_area_lazy ~ # perf stat --repeat 10 -ae workqueue:workqueue_queue_work --filter 'function == 0xffffffff811d0dd0' ./fork Performance counter stats for 'system wide' (10 runs): 15 workqueue:workqueue_queue_work ( +- 0.88% ) 1.615368474 seconds time elapsed ( +- 0.41% ) Without optimization: ~ # grep try_purge /proc/kallsyms ffffffff811d0dd0 t try_purge_vmap_area_lazy ~ # perf stat --repeat 10 -ae workqueue:workqueue_queue_work --filter 'function == 0xffffffff811d0dd0' ./fork Performance counter stats for 'system wide' (10 runs): 30 workqueue:workqueue_queue_work ( +- 1.31% ) 1.613231060 seconds time elapsed ( +- 0.38% ) So there is no measurable difference on the test itself, but we queue twice more jobs without this optimization. It should decrease load of kworkers. >> --- >> mm/vmalloc.c | 3 ++- >> 1 file changed, 2 insertions(+), 1 deletion(-) >> >> diff --git a/mm/vmalloc.c b/mm/vmalloc.c >> index ea1b4ab..88168b8 100644 >> --- a/mm/vmalloc.c >> +++ b/mm/vmalloc.c >> @@ -737,7 +737,8 @@ static void free_vmap_area_noflush(struct vmap_area *va) >> /* After this point, we may free va at any time */ >> llist_add(&va->purge_list, &vmap_purge_list); >> >> - if (unlikely(nr_lazy > lazy_max_pages())) >> + if (unlikely(nr_lazy > lazy_max_pages()) && >> + !mutex_is_locked(&vmap_purge_lock)) >> schedule_work(&purge_vmap_work); >> } >> >> -- >> 2.10.2 >> > -- 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-f70.google.com (mail-oi0-f70.google.com [209.85.218.70]) by kanga.kvack.org (Postfix) with ESMTP id 945F36B03A4 for ; Wed, 5 Apr 2017 06:30:04 -0400 (EDT) Received: by mail-oi0-f70.google.com with SMTP id v16so6038187oia.19 for ; Wed, 05 Apr 2017 03:30:04 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0099.outbound.protection.outlook.com. [104.47.2.99]) by mx.google.com with ESMTPS id 6si3239801oic.240.2017.04.05.03.30.02 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 05 Apr 2017 03:30:03 -0700 (PDT) Subject: Re: [PATCH 1/4] mm/vmalloc: allow to call vfree() in atomic context References: <20170330102719.13119-1-aryabinin@virtuozzo.com> <2cfc601e-3093-143e-b93d-402f330a748a@vmware.com> <20170404094148.GJ15132@dhcp22.suse.cz> From: Andrey Ryabinin Message-ID: Date: Wed, 5 Apr 2017 13:31:23 +0300 MIME-Version: 1.0 In-Reply-To: <20170404094148.GJ15132@dhcp22.suse.cz> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Michal Hocko Cc: Thomas Hellstrom , akpm@linux-foundation.org, penguin-kernel@I-love.SAKURA.ne.jp, linux-kernel@vger.kernel.org, linux-mm@kvack.org, hpa@zytor.com, chris@chris-wilson.co.uk, hch@lst.de, mingo@elte.hu, jszhang@marvell.com, joelaf@google.com, joaodias@google.com, willy@infradead.org, tglx@linutronix.de, stable@vger.kernel.org On 04/04/2017 12:41 PM, Michal Hocko wrote: > On Thu 30-03-17 17:48:39, Andrey Ryabinin wrote: >> From: Andrey Ryabinin >> Subject: mm/vmalloc: allow to call vfree() in atomic context fix >> >> Don't spawn worker if we already purging. >> >> Signed-off-by: Andrey Ryabinin > > I would rather put this into a separate patch. Ideally with some numners > as this is an optimization... > It's quite simple optimization and don't think that this deserves to be a separate patch. But I did some measurements though. With enabled VMAP_STACK=y and NR_CACHED_STACK changed to 0 running fork() 100000 times gives this: With optimization: ~ # grep try_purge /proc/kallsyms ffffffff811d0dd0 t try_purge_vmap_area_lazy ~ # perf stat --repeat 10 -ae workqueue:workqueue_queue_work --filter 'function == 0xffffffff811d0dd0' ./fork Performance counter stats for 'system wide' (10 runs): 15 workqueue:workqueue_queue_work ( +- 0.88% ) 1.615368474 seconds time elapsed ( +- 0.41% ) Without optimization: ~ # grep try_purge /proc/kallsyms ffffffff811d0dd0 t try_purge_vmap_area_lazy ~ # perf stat --repeat 10 -ae workqueue:workqueue_queue_work --filter 'function == 0xffffffff811d0dd0' ./fork Performance counter stats for 'system wide' (10 runs): 30 workqueue:workqueue_queue_work ( +- 1.31% ) 1.613231060 seconds time elapsed ( +- 0.38% ) So there is no measurable difference on the test itself, but we queue twice more jobs without this optimization. It should decrease load of kworkers. >> --- >> mm/vmalloc.c | 3 ++- >> 1 file changed, 2 insertions(+), 1 deletion(-) >> >> diff --git a/mm/vmalloc.c b/mm/vmalloc.c >> index ea1b4ab..88168b8 100644 >> --- a/mm/vmalloc.c >> +++ b/mm/vmalloc.c >> @@ -737,7 +737,8 @@ static void free_vmap_area_noflush(struct vmap_area *va) >> /* After this point, we may free va at any time */ >> llist_add(&va->purge_list, &vmap_purge_list); >> >> - if (unlikely(nr_lazy > lazy_max_pages())) >> + if (unlikely(nr_lazy > lazy_max_pages()) && >> + !mutex_is_locked(&vmap_purge_lock)) >> schedule_work(&purge_vmap_work); >> } >> >> -- >> 2.10.2 >> > -- 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