From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 80368C77B61 for ; Mon, 24 Apr 2023 10:08:29 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C9B506B0071; Mon, 24 Apr 2023 06:08:28 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C4AD16B0074; Mon, 24 Apr 2023 06:08:28 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B11E16B0075; Mon, 24 Apr 2023 06:08:28 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id A24D16B0071 for ; Mon, 24 Apr 2023 06:08:28 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 7184E1C67B1 for ; Mon, 24 Apr 2023 10:08:28 +0000 (UTC) X-FDA: 80715859896.02.ADAC58A Received: from mail-lf1-f41.google.com (mail-lf1-f41.google.com [209.85.167.41]) by imf15.hostedemail.com (Postfix) with ESMTP id 85D24A0010 for ; Mon, 24 Apr 2023 10:08:26 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b="MKjVV/mt"; spf=pass (imf15.hostedemail.com: domain of urezki@gmail.com designates 209.85.167.41 as permitted sender) smtp.mailfrom=urezki@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1682330906; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=TGRdXTGUxejidBeRD+GFF+Q+rYpdKyMKQUn3vZCcPRk=; b=TVs8tl1Uo9El3tmHYhtwpwiY83AyJMYK36b2yZ8jNli5SqoPVHgwXGRZTTnFarL5OTnh6g cleVa+03HqO+1Fv3kSNj4boWeVb4VhkGZR701OmqYLzRPgLXTJ6oQib0R3+5+ZKrTnLC/Q 1bGASulTzoO+6G3J8aoqXYJbAXc6mzM= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b="MKjVV/mt"; spf=pass (imf15.hostedemail.com: domain of urezki@gmail.com designates 209.85.167.41 as permitted sender) smtp.mailfrom=urezki@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1682330906; a=rsa-sha256; cv=none; b=i16JvJY9S8suXa33TbFE4Y0W6965+wtTEB6Gt4Xne+oBaCoiBCFssBOP6vQsITVqeJIfYE o4rWxu0jkQeLOML0S8BCyMenlR5h8bHJBpIA5KJsFKANT9zIKjwoeqJTAhcjrvfPHXAAzo oDob7q0Gnty8/CzU8I7M+p9gsHRU1mE= Received: by mail-lf1-f41.google.com with SMTP id 2adb3069b0e04-4ec8149907aso4513801e87.1 for ; Mon, 24 Apr 2023 03:08:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1682330904; x=1684922904; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:date:from:from:to:cc:subject:date:message-id:reply-to; bh=TGRdXTGUxejidBeRD+GFF+Q+rYpdKyMKQUn3vZCcPRk=; b=MKjVV/mt5tYZwQNqTvd8Kk9tEiCxpQEXSQZtMaopx4vlcbxxhwBlqvwSMq/bPeLVF8 2FXrLGC2jpC2hWEwEc+71az97a6FemRR7YVOTWzjX9HHpHOVYxWwN3Km5OceWErGxDow OSZDn3BRyk5V3HUsAo4F+C/hNOk+AXufMlFPRUUFSGnb4CqwAFUg/VOc1e2rmYNj7z1s 2BMZITMUcTo8tWSbYzySqvvBEArTxgHpho037Hfijoo8rr1RHt/yLG7ctNEKozLIWezJ SJxNv32lp2RwHmC1wOIaWTVhRd1Ll9o/+DKTZ74TM/s3DCiIRx9EBNelcDLPgiSxmz+Z 9Juw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682330904; x=1684922904; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:date:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=TGRdXTGUxejidBeRD+GFF+Q+rYpdKyMKQUn3vZCcPRk=; b=ZA5MVRPkfImomoalGLgXD9i+71fJ/rrKdk6/MVYwZAezfRUh+oPdbyLUlxl2C3chpt K25icRZJY5PyhbWgJHNgc7LD11rOM2FYCSxwNs5XwqPaYr2uJ/I9jmt+HXTghSWEWC6N Sgann5zyI0ALojpsvqk2CUG1YAmnanKI4w0SkREg2b8sfwtM8O1S0B77yUvIeWivxkC/ fTWI+MQXlhheH3F8SriYQlTcIgDostfvhVsCSMy6DRFfQu4ZP88OpuLPu3RXJW79Jkfr /ZIh1diTptWgIDsOuRFvUcoeCu0+6zzHdJJX8xUcwZYmu2bqLvRSTbyo8EZHjz+XIeW8 YZ/A== X-Gm-Message-State: AAQBX9ev73K7G9Ao/ztiDTvwjKjTSk4mOQbe9xk/wg3042KGEoPDPxLk jDDaMy+UCh3hzPxdvUsjGic= X-Google-Smtp-Source: AKy350ZEoHr+KwFz1TEQufTypK5EetXbh0DVT2WpVfTMf4+79VQHmWxDnZVSkmqSw2T1J0OG7Dzkgw== X-Received: by 2002:ac2:5456:0:b0:4db:3a70:e9f3 with SMTP id d22-20020ac25456000000b004db3a70e9f3mr3038874lfn.69.1682330904426; Mon, 24 Apr 2023 03:08:24 -0700 (PDT) Received: from pc636 (host-90-233-222-113.mobileonline.telia.com. [90.233.222.113]) by smtp.gmail.com with ESMTPSA id p1-20020a19f001000000b004eff567ba97sm104847lfc.167.2023.04.24.03.08.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 24 Apr 2023 03:08:24 -0700 (PDT) From: Uladzislau Rezki X-Google-Original-From: Uladzislau Rezki Date: Mon, 24 Apr 2023 12:08:22 +0200 To: Michal Hocko Cc: Uladzislau Rezki , lsf-pc@lists.linux-foundation.org, linux-mm@kvack.org Subject: Re: [Lsf-pc] LSFMMBPF proposal [MM]: Eliminate vmap/vmalloc lock contention Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 85D24A0010 X-Stat-Signature: q9ai3hooz8k8x18btfs543px468wg5q1 X-Rspam-User: X-HE-Tag: 1682330906-687366 X-HE-Meta: U2FsdGVkX1+Fycp3phlgClq9vKiRxlqDWJSfAHF46xYBk/LyM/JWFDe30o40Z/XFECzm/8a4ZJ/7FkdGdzhhRh6nR85D6JLHDeMjX0aGEj5oOguRfkE2wzCD06pM8cxoxMap7pTFlLmdH2SU0WqxvfIUNn4308xRZKMbzm2z9EvAJG+DnPY2esC2FWEswewLw5TeK7YZXlyXRW9ZWBCIRa4UF8ZL5x20E6zO6kmR+xmBaJ4eDldRYzrPkffPq9aSlI02YSg7j9YYFxO8orrw0v76Krt+WolXCCv2Es1/5nPwGDRKne92aFLUCETpZYnils2THOl7nQJnNTzy91y7D0vtNrtjRHlRtQOeE8GAsRM+I5NIKYWnWCAgfOsomIvRGpveeRjQ9d5YGpz4ROPZEP6zLyzbWlxQjPwvbhgCcxIiMUWikEw+xoUBQ/S7D4nxJ6Vv4Hm60/k0KfcmsdYj2dDkJ+8Zv9zaKUz8epn9rPMooSCi4g8ILRY5OvCCsjwykaz31db6qqOju2rsQSP65S+5y2GU08r0FZywutnYB29jy1BH4VR0fqDa13ahiT/j39YJEN675Mv3QjGmsK4Szn7tpNRgArSaiMQfNrTJiXag13Z88ah01UfoQTdrwX8au5X5Y19AehVelpkoaSpFkXNY+y2uwyEIRQ1ly1LBoMz+EYW7jpJbq6S3FEytJI1gEhP+X1/fp/+ApVsoJ2pDKWOl/XMcR/DENUBi6V9WUy4zbrMrOd+mwW02u1JR3fFWuBdMnFlNJY8J+l50z/CzZrFwDYf9PcpqvcNp1JzBbc8EIR0Wqt34hEXd0JLWei045VHx3BnlEusHuos/sXGOlJlU4yLTjfL/+/s2bDU6+m9LyuvNgwAjE/FSGMccON63VVywwI5UbDXh8YXKtbHASZjF+iKknBIE/Fu0Zi9gbXBm2jRkq+LTg67YD8IeDDA1nUfxbFwhBDKaX6m5bwY r3A2CgWP ySUi+rtBKym4ND1CdSFuKHOf/LUA5oK/Few1gjoTaoQZDM/Gbxrq1z1NW17i18J+QvEz+79VbCkrJ0z1DjYzB/6vr9np8WXgl8yn+Dc4I/URgMV5oE9hKOc4gDfZL5ThpTKvb+M/sA5XofJ03ktaDw3t2txdJ7cvUR1ANmMPWTqFlyFr6WGE2Lcdfy9OQpbjWkmR/Hk9d382DH/FNdnVg+qjyn50qTv9ZexB4AOS0T8DTysu4sYfW+5ipKbSu8HyVo7aH3EFMmTKiM40tVGm0sHlMjUXcDMaYlppxmSZPmtalrU0A7Su0hcyiE0NpKRQuBjbh4pkwanvOFkv40l9IskReQ2uz/w537islFgtU0nQaoSdU7CMbZvB0b8VX1yDgpVWwv0TLAYQ6nMbjtBbB6KGhlEzItTMYcpxlEMjR6babqLbAs6oM/e3gjBXordP42Q8p4B4sXOK6lAM= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000018, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Mon, Apr 24, 2023 at 10:55:20AM +0200, Michal Hocko wrote: > On Mon 24-04-23 09:44:00, Uladzislau Rezki wrote: > > On Fri, Apr 21, 2023 at 02:03:43PM +0200, Michal Hocko wrote: > > > On Tue 28-02-23 17:42:43, Uladzislau Rezki wrote: > > > > Hello, LSF. > > > > > > > > Title: Introduce a per-cpu-vmap-cache to eliminate a vmap lock contention > > > > > > > > Description: > > > > Currently the vmap code is not scaled to number of CPU cores in a system > > > > because a global vmap space is protected by a single spinlock. Such approach > > > > has a clear bottleneck if many CPUs simultaneously access to one resource. > > > > > > > > In this talk i would like to describe a drawback, show some data related > > > > to contentions and places where those occur in a code. Apart of that i > > > > would like to share ideas how to eliminate it providing a few approaches > > > > and compare them. > > > > > > It's been some time since you brough this up. Has there been any > > > progress on the topic? Do you still find it important to discuss it at > > > LSFMM? > > > > > The idea about sequence was/is: > > > > 1) Give an overview on the proposal; > > 2) Submit patches to address the problem; > > 3) Start a discussion over lkml with people who are interested in it; > > 4) Send out a complete solution. > > Thanks for the clarification. The usual LSFMM format is strongly > discussion focused. Long presentations are usually discouraged and they > should only introduce people to the underlying problem to kick of a > discussion. > I have not posted yet any RFC and have not kicked it yet. Though people are aware the problem. > > That being said, IMO it would be helpful to have some material on the > mailing list before any discussion could be productive. > This is what i have so far: wget ftp://vps418301.ovh.net/incoming/Fix_a_vmalloc_lock_contention_in_SMP_env.pdf I can, of course, move it forward over lkml only. If you are fully booked or there other reason then please just withdraw my proposal from your conference. -- Uladzislau Rezki