Received-SPF: pass (google.com: domain of linux-kernel+bounces-22870-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
From: Andi Kleen <ak@linux.intel.com>
To: Oscar Salvador <osalvador@suse.de>
Cc: andrey.konovalov@linux.dev,  Andrew Morton <akpm@linux-foundation.org>,
  Andrey Konovalov <andreyknvl@gmail.com>,  Marco Elver <elver@google.com>,
  Alexander Potapenko <glider@google.com>,  Dmitry Vyukov
 <dvyukov@google.com>,  Vlastimil Babka <vbabka@suse.cz>,
  kasan-dev@googlegroups.com,  Evgenii Stepanov <eugenis@google.com>,
  linux-mm@kvack.org,  linux-kernel@vger.kernel.org,  Andrey Konovalov
 <andreyknvl@google.com>
Subject: Re: [PATCH v4 12/22] lib/stackdepot: use read/write lock
In-Reply-To: <ZZUlgs69iTTlG8Lh@localhost.localdomain> (Oscar Salvador's
	message of "Wed, 3 Jan 2024 10:14:42 +0100")
References: <cover.1700502145.git.andreyknvl@google.com>
	<9f81ffcc4bb422ebb6326a65a770bf1918634cbb.1700502145.git.andreyknvl@google.com>
	<ZZUlgs69iTTlG8Lh@localhost.localdomain>
Date: Wed, 10 Jan 2024 15:01:36 -0800
Message-ID: <87sf34lrn3.fsf@linux.intel.com>
User-Agent: Gnus/5.13 (Gnus v5.13)
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain

Oscar Salvador <osalvador@suse.de> writes:
>> 
>> With this change, multiple users can still look up records in parallel.

That's a severe misunderstanding -- rwlocks always bounce a cache line,
so the parallelism is significantly reduced.

Normally rwlocks are only worth it if your critical region is quite long.

>> 
>> This is preparatory patch for implementing the eviction of stack records
>> from the stack depot.
>> 
>> Reviewed-by: Alexander Potapenko <glider@google.com>
>> Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
>
> Reviewed-by: Oscar Salvador <osalvador@suse.de>


Has anyone benchmarked this on a high core count machine? It sounds
pretty bad if every lock aquisition starts bouncing a single cache line.

Consider using RCU or similar.

-Andi