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 C378CC7618E for ; Fri, 21 Apr 2023 12:03:49 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2BD916B0071; Fri, 21 Apr 2023 08:03:49 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 26DD36B0072; Fri, 21 Apr 2023 08:03:49 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 136156B0074; Fri, 21 Apr 2023 08:03:49 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 016C46B0071 for ; Fri, 21 Apr 2023 08:03:48 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id C3DE71A0428 for ; Fri, 21 Apr 2023 12:03:48 +0000 (UTC) X-FDA: 80705264136.27.77D0377 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by imf11.hostedemail.com (Postfix) with ESMTP id E37B14001F for ; Fri, 21 Apr 2023 12:03:45 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=IIxrlAvb; spf=pass (imf11.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.29 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1682078626; 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=MV9Q8BddIlIg+jJNOWWCxg2d7N11WKp3AjKT48RW8XU=; b=nvBm+xVI1LzcUR4vXPWNgdPBa+rH0KyfeOY4npc64ufB4jmCOP3b2f3RNymcbO5bg3e7jz 5LZ5cyyMDGBnzp/axUw7M1i3iv4WKv9hnX2JQ6uH4FNRnwf05GOsiE8K42pODFMzMrLrUl luTN8BWrBDPZBjrsjt91hg0LpAZiCjw= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=IIxrlAvb; spf=pass (imf11.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.29 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1682078626; a=rsa-sha256; cv=none; b=QJ4n7Md1HGRlry0CL47AbdwlFF/xTj81bXFmBjsfxWtYMFr1IlWcfhyk+HNssYzwOz7Mtm IkNig9EIGkYqpGoYR8ECHZdVtLDk6krygf8GheMBMReBdsUAOylVrOxXQdy4PTvc5rP9/5 Qm/l6nUDIROX+/xRotc2ckgbe/TmVbg= Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 622621FDDC; Fri, 21 Apr 2023 12:03:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1682078624; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=MV9Q8BddIlIg+jJNOWWCxg2d7N11WKp3AjKT48RW8XU=; b=IIxrlAvbG3hW/0pjhrKl6+MV0JB4A9dxXoYBBwad28Mm4vhCXF00dBaUkNzG4ed4zHL8w3 s7eVQH7kHSVLwyXD+oBoAneV6kktcnzvodsunT1JEpHRHmWB4AuaEDeZYE7PyMXVnRfIt9 d4XrPB8dEJc/qlXzHS+Ja0ER/qow5FU= Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 41A3A13456; Fri, 21 Apr 2023 12:03:44 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id U+zADaB7QmQYKQAAMHmgww (envelope-from ); Fri, 21 Apr 2023 12:03:44 +0000 Date: Fri, 21 Apr 2023 14:03:43 +0200 From: Michal Hocko To: Uladzislau Rezki Cc: 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-Stat-Signature: su8punextd7o1q1pogrykbsznemyf5se X-Rspam-User: X-Rspamd-Queue-Id: E37B14001F X-Rspamd-Server: rspam06 X-HE-Tag: 1682078625-660248 X-HE-Meta: U2FsdGVkX1+R14da91RfMe2rPhQLrWhDGjxXv4hWlmj7Q56BMl2b/ne6iVCM/2vnHbJiVwYZxcarxThhOSVqXWdERDKraUNKKflPt69kyIa8baDgOXddgSXR08ZwWRZuJIJv1jKIcFO616TyiKvy1vXv+kX1vwL+npjcCzWR5CwgCwsQaLTxx/AciLJK6uCDhtQUzC2mNWYlLu790G2jwDsBNdYajW7pSDxn3OnmF9FPYreoizJ8IEEX6YOrE+PnaQafAHIecbRPkkYDxZe+/Qn6dldSpNeXThtvBDvrgmUGI5mhCCZF+Vlkivvs8X1JE636+RLLqrJu3SB1v+vx3OcGmES3yF1UKb5y/sw1OjiU6cnt1QdH7iPvgZi6uwgvKPV614qEZqGdyQd4kF+cgSmDIbdcZYusNueUwAYopd+BeLyK20k9CYfJcwhZkv8nZDK34TXM9PtfUDAM+8QqhPgqG87HgJTQy1//47qmQKMh4ASnB2MyWcH4eSEJrbUjDevzeT5LOLjD+4rXxKw2dGeNaDdHxXRFcOcYnHykTDwXPBnJZgOPDx8HZ5apIFVdS2hVF1HPJm9+5wb4vGjCqqvCFIBjWq4Kbo7HbzFx9nv9h+oCYkLnyqGLOuGVTyiKczNcy1Ve51pBuSw7AM+TwGZH6xKtnalx2hqb+/wv2nSWeJc1BxyED2qjW8o+BJ+lQYaIsXzzwxNagyLjgR+utqOzYeYcf2QdwfPKSQIUfMsTdnZdYgcm8gwRxB6hYMpXKqUy2yOAbqtZqrVqVTXznuXUV7ZYh/6WMyZjnt6YwwVBOIL9aRlpVGxWpMIRCPcPGprY8wOwi7bx23467j6ejjBway+WcmpLWeLtC6PvI1pipx6eA+bxrUVE+FDvnRe/MSB2TFkJXJhP5bECkVBaiRNPex5aYyyeYMM27NsMftGYVdxw7cEmC7+i00G3ZCy/mjJvT8RfYdLH3CMMfqz r+WCCZ7Z 4xCLgl9F9Kt07MJP06MUWOzaT5vwdhhZpSj3WSb/Ri++wuxVFZSroY7dnu8OLnCKSxhG5vpnOa4+t0KCW7dTOpuMbjn1/aB1I62XkDFbQIu9wYqGWD/tHfE7ROPclw4HHKJmswj9aZKcjwSHzIe7sddIZAzMopJQh5fOtahT4iFdyI+9sNKcP6oTo3DqYQy9M+lQsM02leOJ/0GKJqhTlHd99Ts1YeHx/QQlgkNor5rWNaAT+aciYb6Fe/dJq2DuBzn6G2scg8bjX0mU= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: 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? > Requirements: > * It should be a per-cpu approach; > * Search of freed ptrs should not interfere with other freeing(as much as we can); > * - offload allocated areas(buzy ones) per-cpu; > * Cache ready sized objects or merge them into one big per-cpu-space(split on demand); > * Lazily-freed areas either drained per-cpu individually or by one CPU for all; > * Prefetch a fixed size in front and allocate per-cpu > > Goals: > * Implement a per-cpu way of allocation to eliminate a contention. > > Thanks! > > -- > Uladzislau Rezki > _______________________________________________ > Lsf-pc mailing list > Lsf-pc@lists.linux-foundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lsf-pc -- Michal Hocko SUSE Labs