From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) (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 1D3CC3290D1 for ; Tue, 7 Apr 2026 09:07:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=90.155.50.34 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775552879; cv=none; b=tKqzTUkL1PvmAAXXKKx4hOn6yO7J/lLyDDtPpmQ1sLl0fV10UTYJW+nhUV538oQkThLZRRWphdZoNpSugrvv5bMIdcM/x3utKHiQAObwn8KUebQ/v5w3mn6G+a4Ej7L8obO/gL4665MzgAnjEHnp0wDpnIq3ZsHfeVCIw6O8PQk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775552879; c=relaxed/simple; bh=OGWnMVLcd2JEiAjZlT2jJs0ECzzeYjyTNvwDqPsoXAI=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=qNZ5lKpo9EmSIIluR4DbRaFLf8+9jDxDEA+8lPJ7I4HTi0BwdigbDBMUYtdscdwKSrMDTcPFfmaZXvSzYvJCPaF3IuD3M6YJUW1xB+UjgLmmKpTA9LHKiqRXqMgsrtAjVKV0Q1m5HvaTvYnzWo+JLM2C0cApe4yt8WEQFBpwt44= 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=SmEL6zUC; arc=none smtp.client-ip=90.155.50.34 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="SmEL6zUC" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; 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=8JGTyJeoa9bFSknhxKmd9zRw+wAYJKnRmHV83mQGelY=; b=SmEL6zUCwT6jJm6DlOAqMIbvMM I7S8OzXXPDVbHf+08pDlXhqCdfJYi5r1ZgrYbSYcIBBWRZo7mJve58N07z8CirbObVFYlsBRuNIS+ eUEOhgibl7YoXQQRwb2aTu44OfW8j9S5alhG7fBYEYe+Bj3TqluKwWPOFkfKaZMGsgh9hnCtxXPBy L2M5JgjVcGQx1VAfwGXVfXBtLCDl9lWjqtbtxEawY3qDZod2a6bQLrFuwubPijWEHLTIs6f2XXODb Glj9wtHH5iNKIZ8Mlox4EbDSZUS1tn8rpoIJMe1ikfIMEmYcCjoAVkGAWgY8dpAKI2oBByXiOJCjm 3cavZ21A==; Received: from 2001-1c00-8d85-4b00-266e-96ff-fe07-7dcc.cable.dynamic.v6.ziggo.nl ([2001:1c00:8d85:4b00:266e:96ff:fe07:7dcc] helo=noisy.programming.kicks-ass.net) by casper.infradead.org with esmtpsa (Exim 4.98.2 #2 (Red Hat Linux)) id 1wA2PY-00000003Ixf-0kgn; Tue, 07 Apr 2026 09:07:52 +0000 Received: by noisy.programming.kicks-ass.net (Postfix, from userid 1000) id 74DB130035C; Tue, 07 Apr 2026 11:07:50 +0200 (CEST) Date: Tue, 7 Apr 2026 11:07:50 +0200 From: Peter Zijlstra To: Ritesh Harjani Cc: Andres Freund , 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: <20260407090750.GQ3739106@noisy.programming.kicks-ass.net> References: <20260403191942.21410-1-dipiets@amazon.it> <20260403213207.GF2872@noisy.programming.kicks-ass.net> <1pgulz0k.ritesh.list@gmail.com> <20260407082018.GC3738010@noisy.programming.kicks-ass.net> 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: <20260407082018.GC3738010@noisy.programming.kicks-ass.net> On Tue, Apr 07, 2026 at 10:20:18AM +0200, Peter Zijlstra wrote: > On Sun, Apr 05, 2026 at 11:38:59AM +0530, Ritesh Harjani wrote: > > > However, for curiosity, I was hoping if someone more familiar with the > > scheduler area can explain why PREEMPT_LAZY v/s PREEMPT_NONE, causes > > performance regression w/o huge pages? > > > > Minor page fault handling has micro-secs latency, where as sched ticks > > is in milli-secs. Besides, both preemption models should anyway > > schedule() if TIF_NEED_RESCHED is set on return to userspace, right? > > > > So was curious to understand how is the preemption model causing > > performance regression with no hugepages in this case? > > So yes, everything can schedule on return-to-user (very much including > NONE). Which is why rseq slice ext is heavily recommended for anything > attempting user space spinlocks. > > The thing where the other preemption modes differ is the scheduling > while in kernel mode. So if the workload is spending significant time in > the kernel, this could cause more scheduling. > > As you already mentioned, no huge pages, gives us more overhead on #PF > (and TLB miss, but that's mostly hidden in access latency rather than > immediate system time). This gives more system time, and more room to > schedule. > > If we get preempted in the middle of a #PF, rather than finishing it, > this increases the #PF completion time and if userspace is trying to > access this page concurrently.... But we should see that in mmap_lock > contention/idle time :/ Sorry, insufficient wake-up juice applied. Concurrent page-faults are serialized on the page-table (spin) locks. Not mmap_lock. So it would increase system time and give more rise to kernel preemption.