From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C246A3939D6 for ; Tue, 7 Apr 2026 08:28:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=90.155.92.199 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775550486; cv=none; b=kc09Urj/rwqbggi0MiATAlhnTZvJAMiDQ4EfSx9+9W22NGczt6eTxvhqwaDc4OGDzuolgWxUhqIfSzTobc0g7bW6r8URrDCLquIsLhbj4QGy/Jlgd2kQqf82oY2Zdg7yvt45ah6/X5xpdWBSVYzQKwTJ0wGXFQCVW12oF7f0c7Q= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775550486; c=relaxed/simple; bh=EVIgB9k4LHNBMIT3GtyaAb/YkegDGCKIFyop13hIehM=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=VUJjSKZaZ0gnAKqNZ+sSHgPGw2XySjhTXTjVfEmqUNxXYKlZ2MwYPfUk8rIfrA/CLPlkCbPE0Q4/ix5mMVmxp1CVaNvg/8dQEj/3tKdb5NmFgWGADuJqt2tUZiQJecOT9PlvqbY41L7PSrJne5bd3/9ivwFpmtLNhWwm09Qfpts= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org; spf=none smtp.mailfrom=infradead.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b=DGYpJ2+V; arc=none smtp.client-ip=90.155.92.199 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=infradead.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="DGYpJ2+V" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=desiato.20200630; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=/94ovejkSJrVorMeUAMZMWPVdA1s3x0Sv5hi+KIt5FA=; b=DGYpJ2+V3sW7qjbpPfU8HAfhRF g44dZjB70kmv8s8x0Uh6Ncpp094NMOhw4qORDAfmdKvxbKXACpvy0vP8tLRXy8vGe1KlUXHiYHn+/ 8sDPR2gUcoH8/tQL/0yGPXI5cBORNJNhqe/qine81Ov3YggoZwHPJmbzgISDVLpwcEMpAN0hJPP86 b0yWk3n5wynHRBmhcBz22jDfwV4RYpORTR41XkuwfDhuchQ3x15dUj0DTsxy3iQLI8af047lT/0RH 7DjG+bELN4sm+1SnKp0RkyyE9CNBeBbGsi3KC2yY/tVvXVbUUUOqgkOHoK978xisL2RLSGPfpO13R eBuk0fog==; Received: from 77-249-17-252.cable.dynamic.v4.ziggo.nl ([77.249.17.252] helo=noisy.programming.kicks-ass.net) by desiato.infradead.org with esmtpsa (Exim 4.98.2 #2 (Red Hat Linux)) id 1wA1ms-00000007q93-2kdy; Tue, 07 Apr 2026 08:27:54 +0000 Received: by noisy.programming.kicks-ass.net (Postfix, from userid 1000) id 0F7833005E5; Tue, 07 Apr 2026 10:27:54 +0200 (CEST) Date: Tue, 7 Apr 2026 10:27:54 +0200 From: Peter Zijlstra To: Andres Freund Cc: Ritesh Harjani , Salvatore Dipietro , linux-kernel@vger.kernel.org, alisaidi@amazon.com, blakgeof@amazon.com, abuehaze@amazon.de, dipietro.salvatore@gmail.com, Thomas Gleixner , Valentin Schneider , Sebastian Andrzej Siewior , Mark Rutland Subject: Re: [PATCH 0/1] sched: Restore PREEMPT_NONE as default Message-ID: <20260407082754.GD3738010@noisy.programming.kicks-ass.net> References: <20260403191942.21410-1-dipiets@amazon.it> <20260403213207.GF2872@noisy.programming.kicks-ass.net> <1pgulz0k.ritesh.list@gmail.com> <4q4zsstjeef63sdkl2az3tziy3etorzzxyt2k4nhwokpmegsr3@y6w76kosjzts> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4q4zsstjeef63sdkl2az3tziy3etorzzxyt2k4nhwokpmegsr3@y6w76kosjzts> On Sun, Apr 05, 2026 at 10:09:35AM -0400, Andres Freund wrote: > FWIW, from what I can tell, the whole "WHAA, it's a userspace spinlock" part > has just about nothing to do with the problem. :-) > My understanding is that > default futexes don't transfer the lock waiter's scheduler slice to the lock > holder (there's no information about who the lock holder is unless it's a PI > futex), (and robust; both PI and robust store the owner TID in the futex field) The difference is that while mutex lock holder preemption is also bad, it mostly just leads to idle time, which you can sometimes fill with doing other work. Whereas with spinlocks, the time gets soaked up with spinners. So both 'bad', but both different. > Postgres' spinlock have randomized exponential backoff and the amount > of spinning is adjusted over time, so you don't actually end up with spinlock > waiters preventing the lock owner from getting scheduled to a significant > degree. Fair enough.