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 X-Spam-Level: X-Spam-Status: No, score=-7.7 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id DC6AAC432BE for ; Fri, 6 Aug 2021 07:45:15 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 431EF61208 for ; Fri, 6 Aug 2021 07:45:15 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 431EF61208 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.cz Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 79CD86B006C; Fri, 6 Aug 2021 03:45:14 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 74D158D0001; Fri, 6 Aug 2021 03:45:14 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 614F96B0072; Fri, 6 Aug 2021 03:45:14 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0159.hostedemail.com [216.40.44.159]) by kanga.kvack.org (Postfix) with ESMTP id 452626B006C for ; Fri, 6 Aug 2021 03:45:14 -0400 (EDT) Received: from smtpin03.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id D8D411AA6C for ; Fri, 6 Aug 2021 07:45:13 +0000 (UTC) X-FDA: 78443870106.03.536129C Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf27.hostedemail.com (Postfix) with ESMTP id 4534D700196F for ; Fri, 6 Aug 2021 07:45:13 +0000 (UTC) Received: from imap1.suse-dmz.suse.de (imap1.suse-dmz.suse.de [192.168.254.73]) (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-out1.suse.de (Postfix) with ESMTPS id BE6312236C; Fri, 6 Aug 2021 07:45:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1628235911; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=XydYnpc/ls5Im9aJguL/IFsvkaJWo5CzHRaUo1rP4fg=; b=zs1SFy6zUm/lB9EgyDvbcRcfVvTba1V3FNEw8cjNvaFI82nmKYw7NRXbxruqQjxRMxpvXg s/KOlugwd1kTgFSV3maXoThKrIKqJ+eh+VyKY/I47Pe3zd+vYZBHGEKJaMk9gn3WE15Dzl +l3JifFaTsJhzwDf6KDAc1APQpE/XwU= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1628235911; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=XydYnpc/ls5Im9aJguL/IFsvkaJWo5CzHRaUo1rP4fg=; b=+VrSlps7ivv7Q7Bc4P0TErE0eBwkbpf2hTDCk9GEZN8pdpffvlizIK630SrQ8k76iFcZrw t+3HFgfFXW4+YwDw== Received: from imap1.suse-dmz.suse.de (imap1.suse-dmz.suse.de [192.168.254.73]) (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 imap1.suse-dmz.suse.de (Postfix) with ESMTPS id 8560F13990; Fri, 6 Aug 2021 07:45:11 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap1.suse-dmz.suse.de with ESMTPSA id AR5FH4foDGGdGAAAGKfGzw (envelope-from ); Fri, 06 Aug 2021 07:45:11 +0000 To: Mike Galbraith , Sebastian Andrzej Siewior Cc: Andrew Morton , Christoph Lameter , David Rientjes , Pekka Enberg , Joonsoo Kim , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Thomas Gleixner , Mel Gorman , Jesper Dangaard Brouer , Jann Horn References: <20210805152000.12817-1-vbabka@suse.cz> <20210805164210.2zxpzn2sdogf4kx3@linutronix.de> From: Vlastimil Babka Subject: Re: [PATCH v4 00/35] SLUB: reduce irq disabled scope and make it RT compatible Message-ID: <918557ec-3d8c-3d54-bce9-730f3a9cdc2d@suse.cz> Date: Fri, 6 Aug 2021 09:45:11 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 4534D700196F Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=zs1SFy6z; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=+VrSlps7; dmarc=none; spf=pass (imf27.hostedemail.com: domain of vbabka@suse.cz designates 195.135.220.28 as permitted sender) smtp.mailfrom=vbabka@suse.cz X-Stat-Signature: ehzg94z8h7g861bs59qw3an11erf99m5 X-HE-Tag: 1628235913-358804 Content-Transfer-Encoding: quoted-printable 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 8/6/21 7:14 AM, Mike Galbraith wrote: > On Thu, 2021-08-05 at 18:42 +0200, Sebastian Andrzej Siewior wrote: >> >> There was throughput regression in RT compared to previous releases >> (without this series). The regression was (based on my testing) only >> visible in hackbench and was addressed by adding adaptiv spinning to >> RT-mutex. With that we almost back to what we had before :) >=20 > Numbers on my box say a throughput regression remains (silly fork bomb > scenario.. yawn), which can be recouped by either turning on all > SL[AU]B features or converting the list_lock to a raw lock. I'm surprised you can still do that raw lock in v3/v4 because there's now= a path where get_partial_node() takes the list_lock and can call put_cpu_partial= () which takes the local_lock. But seems your results below indicate that th= is was without CONFIG_SLUB_CPU_PARTIAL so that would still work. > They also > seem to be saying that if you turned on PREEMPT_RT because you care > about RT performance first and foremost (gee), you'll do neither of > those, because either will eliminate an RT performance progression. That was my assumption, that there would be some tradeoff and RT is willi= ng to sacrifice some throughput here... which should be only visible if your be= nchmark is close to slab microbenchmark, as hackbench is. Thanks again!