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 87733C43334 for ; Wed, 8 Jun 2022 10:06:05 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 17FEF8D0022; Wed, 8 Jun 2022 06:06:05 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 12F7D8D0021; Wed, 8 Jun 2022 06:06:05 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 01E838D0022; Wed, 8 Jun 2022 06:06:04 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id E82088D0021 for ; Wed, 8 Jun 2022 06:06:04 -0400 (EDT) Received: from smtpin31.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id C3F30610D4 for ; Wed, 8 Jun 2022 10:06:04 +0000 (UTC) X-FDA: 79554637848.31.9495532 Received: from mail-ej1-f46.google.com (mail-ej1-f46.google.com [209.85.218.46]) by imf24.hostedemail.com (Postfix) with ESMTP id 5F42918005F for ; Wed, 8 Jun 2022 10:06:04 +0000 (UTC) Received: by mail-ej1-f46.google.com with SMTP id me5so39899895ejb.2 for ; Wed, 08 Jun 2022 03:06:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=C+skOxNEIDVYZr0JcmYzlab0ebLbIZBRhQJGr7c39G4=; b=YIIoDUrf1gn3sMbVP9TDvyB4fG67sjhT3RN1xXqKIK1m+azW1yU18YfgFcbsWpzZW0 58iTKb8RAOYnpEF93ro4uF8G8ZfBhpLkWmivCMKF+5r/lvY8N5aa74rM+IekeyELH4TD 0IBJpeDQikhBFji9cdvguSMSwZnsqWDclFZ+fFyi36mL7iAr1msJw60zdFbJgdxVehqG nvvFzSpKSKRk9uQiGcZugzhRvuYUZxu+2CIizx4wo8ZIh+jBOYYc7XnIo6hryd1n7gig 4Wvpuv2sLD445Q3ROyVdcsbQhfsRvMjGGBT+2RwAR7FdfMvZFUBUZ6XP+ua8917slTSU GnTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=C+skOxNEIDVYZr0JcmYzlab0ebLbIZBRhQJGr7c39G4=; b=Wv13oZ0v/eKq9Fa48iJQXsD/dOABwbu76N8U7EyWc/Kq0oCJ/kbK+2RRhe+b5I33bj QwPg7fMjRk9dRXYtL21E8ii4xC7kXbj+SR8/GxaglqDYDWTth0eoMf0Sdkgpq8KNjoL/ 4SJ13DkBb30XhwOXQq2rbB9ZdMNFGgc+QJ4s8a/Fci9ZzJYNVvOdHaQQpfQOUXUmJGjM px4l5ku0rqjYKo1E8ugo9Px24d9c3dORxuSWzSA5nbwoACbGz4VEKsJ54klS9GqWd1hV 0SlDqOmuGGvwUFxYqBOI2HD9q8/9V/5I5Y42nDjXjx6OjMskbieKSAykDjKoKOqxTdwo hARA== X-Gm-Message-State: AOAM533OmSGesWJoeUZy3JzkvNEz9npehQD2tRosHR4oRSRm1YFGYpOC k9hbzF2Xn03A1iP9BRCD1apFerCDXgL3s1rYEjc= X-Google-Smtp-Source: ABdhPJxH/rCMTjSkW93eQ5uIIfUxxl9yBuGOUyJ88qK8lSm54ekA6mu1UjrYoPfQ6ntVCbJbqcSc1yBhFpRyjuUDDRc= X-Received: by 2002:a17:906:c302:b0:6fe:a216:20a4 with SMTP id s2-20020a170906c30200b006fea21620a4mr31611419ejz.556.1654682763093; Wed, 08 Jun 2022 03:06:03 -0700 (PDT) MIME-Version: 1.0 References: <20220607093449.3100-1-urezki@gmail.com> <20220607153544.7727e87f669ea3a7c9f4a6b5@linux-foundation.org> In-Reply-To: <20220607153544.7727e87f669ea3a7c9f4a6b5@linux-foundation.org> From: Uladzislau Rezki Date: Wed, 8 Jun 2022 12:05:50 +0200 Message-ID: Subject: Re: [PATCH 0/5] Reduce a vmalloc internal lock contention preparation work To: Andrew Morton Cc: linux-mm@kvack.org, LKML , Christoph Hellwig , Matthew Wilcox , Nicholas Piggin , Oleksiy Avramchenko Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 5F42918005F Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=YIIoDUrf; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf24.hostedemail.com: domain of urezki@gmail.com designates 209.85.218.46 as permitted sender) smtp.mailfrom=urezki@gmail.com X-Stat-Signature: mrhxpryawg47775o5o1ksg38ujsapggq X-Rspam-User: X-HE-Tag: 1654682764-704939 X-Bogosity: Ham, tests=bogofilter, spamicity=0.007651, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: > > I can toss it in for some runtime testing, but... > > What lock are we talking about here, what is the magnitude of the > performance issues it is causing and what is the status of the patch > which uses all this preparation? > 1. The vmalloc still uses the global lock in order to access to the global vmap space. As for magnitude it depends on number of CPUs, higher number higher contention. Linear dependence. 2. I am not aware about performance issues which i run into on my setup, from the other hand there is a "Per cpu kva allocator" built on top of vmalloc. See vm_map_ram() vm_unmap_ram(). Having vmalloc-per CPU we can get rid of it. It is used by the XFS, f2fs and some drivers. The reason is that a vmalloc is costly due to internal global lock. That is why those users go with "Per cpu kva allocator" to accelerate their workloads. 3. My synthetic test shows a big difference between per-CPU vmalloc patches and default variant. I have different prototypes based on various ways how to make it per-CPU. I still do not have a fully solution that satisfies all the needs. But i do not think it is possible due to many constraints. 4. This series is not tighten to future per-cpu-vmalloc patches, it is rather makes the vmalloc code to be more generic as a result of such common code it would be easier to extend it to per-cpu variant. It means if per-cpu is not in place it is not needed to be reverted back. That is the status. -- Uladzislau Rezki