From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-oi1-f181.google.com (mail-oi1-f181.google.com [209.85.167.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 31AAB2F7AAB for ; Thu, 26 Mar 2026 22:26:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.167.181 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774564021; cv=none; b=s9CBg54Cr73+ILduYju+qwoDIkjOYAe1vIle71jfRsXftViQsfu0a9FwT5EtbtcWZgfJIbxXMFWAqpsBKAzHkG0qReq6hja0Ae2kpyhHEBArzIXrcsCgp66L++fG8xqlFvNKydJbFnipEyT4dT7Z7RnbVlVCbuYmNAIXAf7zZg8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774564021; c=relaxed/simple; bh=xD7ounYKK5COPrz8WDsmFJcQ1xvwNPJvDFSdIx8ypPU=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=lyYkZs4QFwwJQjAv/k5g4NtCk5JkSi0YAza0mXPfdbvGWjOTdtv3pC1qUGl6HZC1VR2Ey6QJX5+l3wnWYbORlXh663lSl3JdK8l9a/uO5eWaljISgZWHA+Rhz5KPQB4MM0M5indesensThhgwFxalpcwnSo7zxHQTgpTY8w0pGU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.dk; spf=pass smtp.mailfrom=kernel.dk; dkim=pass (2048-bit key) header.d=kernel-dk.20230601.gappssmtp.com header.i=@kernel-dk.20230601.gappssmtp.com header.b=ug0ezJ4/; arc=none smtp.client-ip=209.85.167.181 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.dk Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=kernel.dk Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel-dk.20230601.gappssmtp.com header.i=@kernel-dk.20230601.gappssmtp.com header.b="ug0ezJ4/" Received: by mail-oi1-f181.google.com with SMTP id 5614622812f47-4670464029eso835987b6e.2 for ; Thu, 26 Mar 2026 15:26:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel-dk.20230601.gappssmtp.com; s=20230601; t=1774564018; x=1775168818; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=18HfZ25GwqMq2SxJexJDcxFY3ZL1jABpdBiX7SQzd+k=; b=ug0ezJ4/+dJk1mUKtjt0ALrsFE65lGfBdezvJCCTIXBfNaYtgtBZMYEeuTiv9fXMPe JGKymBVB9N00AaTzTQWaOVtv7ELIcEZm8DSiy0XNlGzby/ZjDhuUyjMJX39ibKMR6tPv FQ7b7hPXyNFngOeAgLRxsg0MnrK4juqvMH3kwsTt3ohSR82nVWyzoA9GtormwVKF+sLI i5W71O/JhFozaVwyGSUS/e6H8jv4mcQxkG/T6JszPEwEiopkLi+fLcbaV4a4e3gX8qCz 4T6u8CGVRiBPLjtLOl9RVGg0GB3wIlIkW6rJm8o1kQm73zlzDI7xrqTMzf3zAJbU/FFT zYUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1774564018; x=1775168818; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=18HfZ25GwqMq2SxJexJDcxFY3ZL1jABpdBiX7SQzd+k=; b=gkb837Ozs8HdVeL7R0j7sR4RScyeu1b7sVahXQrHG42MqCpG6+VOOLbJaAJKgUXAiK tKIsQvXHvA2WX24BYkZ7ZbHP0dQwwRLPRTyzU9aAmRfJFsYzm5qmNs7x0gTrDAMJXm1u c413/2XgEhuj9w2Fmczd/R5Mms/N4H+uYQ3iaVW9y4kJJWtgos27rMV0QMhf88VpbgAm ei5T08iw2ZJ1k0ijtDxpAhxh3zmcCgHPLxeyPddsi/S6rqccIJq+lRyUFmNa5ECAMjZ7 QA3siCTz8iEVWNUu2cRVSuYq2fqooN0u2R2gv4TvhGNufr7oxmyLe1ZUMg8w1rjdGbYI vxkg== X-Forwarded-Encrypted: i=1; AJvYcCWedAOOFNFUOdZbyD8tDVDD6MC28UypKr+35OC63s64TOfm2EPWMm7K1yOCbTvKu/7tETy3C/iENlNvOa4=@vger.kernel.org X-Gm-Message-State: AOJu0YxcggllnBNV7jYlA5RdM9X7ooxAOHO/U1z3a6kqwcrus+SI6iSv SA1GCwh6tfCCbLSt2K/pkV9gxgXFIx5P5TmKIDUBNkiG49Urt6ytKM2SU/r533v0jrHLGmjSNnB hV1/EzWI= X-Gm-Gg: ATEYQzzSVUcvX0aIwCYC0MI2jLp0vCELT1yZ/pjJxL/2i+zTyKHlLE5Cka2gTVCPHRI v9mK7iku0kHukUM9k7E+U6uC0AIZDbw/m0+6Uh4w6+TXQ2RrVgWYPe8kTRLC5ApPkZPWdFlx4ok nLvSS5cwSqVgUpvuyHf4GI8LMD97SOsOrm9g6FHJFCPsiG4nIhEpvhaexSFfZyZGTEq0IKm++tP ZOppELEdP0avMokbSlqKBkxxGb5jTfcd4Sqw1eyoPP/Dpoho4xWl0UpZcgvA5vQC86dd5kK0k7N 7k2A95vEW8f0mHuwKtTaBE7zc089gQReIb2UK+B/wm5fRlGNAVkSPeDeRqTge0bQeUEFdjmJpEJ 3m2YpbFM0J/3HHoQdaG9bLc6+fWkEHKLIcTdqRUq0VaFSPv1nU+2/5TXv1oiWJO1GNqZSxVP943 6XqMFnvhUrIwJ4lcwYqAOJeoHt1/qTlnpcA/P8yC/Jqa06jhnsfMz7axtI65/eJJ/wU95Jn1siX YmLVjyLTg== X-Received: by 2002:a05:6808:6f85:b0:466:fd68:c876 with SMTP id 5614622812f47-46a8a6c522emr73701b6e.53.1774564017780; Thu, 26 Mar 2026 15:26:57 -0700 (PDT) Received: from [192.168.1.150] ([198.8.77.157]) by smtp.gmail.com with ESMTPSA id 5614622812f47-46a70adc611sm2269435b6e.17.2026.03.26.15.26.56 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 26 Mar 2026 15:26:57 -0700 (PDT) Message-ID: <8f83728f-5a7a-4088-965a-2647dcbcbd32@kernel.dk> Date: Thu, 26 Mar 2026 16:26:55 -0600 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 0/3] x86/fred: enable FRED by default To: Andy Lutomirski , "H. Peter Anvin" , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , the arch/x86 maintainers Cc: "Peter Zijlstra (Intel)" , Kees Cook , Xin Li , "Ahmed S. Darwish" , Sohil Mehta , Linux Kernel Mailing List References: <20260325230151.1898287-1-hpa@zytor.com> Content-Language: en-US From: Jens Axboe In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 3/26/26 4:11 PM, Andy Lutomirski wrote: > > > On Wed, Mar 25, 2026, at 4:01 PM, H. Peter Anvin wrote: >> From: H. Peter Anvin (Intel) >> >> When FRED was added to the mainline kernel, it was set up as an >> explicit opt-in due to the risk of regressions before hardware was >> available publicly. >> >> Now, Panther Lake (Core Ultra 300 series) has been released, and >> benchmarking by Phoronix has shown that it provides a significant >> performance benefit on most workloads: >> >> https://www.phoronix.com/review/intel-fred-panther-lake > > Those performance increases while with fio / io_uring are ridiculous. > I wonder whether anyone can looked at /proc/interrupts to try to > figure out what's going on. I imagine we're bottlenecking on IO > interrupts or something and FRED speeds that up by a factor of > several, but this makes me wonder whether there's some tuning that > should be done. I did see those results and was wondering myself what on earth is going on there. The IOPS rate isn't anywhere near high enough to saturate a single core (I saw 3-500K IOPS). I probably would've configured some polled nvme queues and ran polled IO to compare. I'm almost pondering if it's some power saving or whatever going on, and timing is enough to mess with it and change the outcome. Because outside of that, I'm a bit puzzled. I don't have a panther lake or any system that supports FRED, so all I can do is guess from here. > Jens, for background, FRED ought to speed up page faults and > interrupts (both IPI and device) by a considerable amount -- maybe a > reduction of 20k or more cycles per interrupt. But Phoronix is > showing up to a factor of 2 (!) actual performance increase using > io_uring with a job count of 8. Now maybe 8 is too small, but I'm > wondering whether the io_uring or IO part is missing some optimization > that it ought to have. He's using fio, which should do the right thing. I'm assuming job count means "8 threads doing IO", but I also don't know what the setting of each job is. Presumably each job drives a queue depth of as well? With perhaps batching on the submission and completion side. Or maybe 8 jobs is a single IO thread, driving QD=8? Sorry, not much I can help with here, without having access to the system and knowing exactly what was run. And I'd also want to poke at it while it's running to get an idea of what is going on. An O_DIRECT 4k random write going from 280K to 500K IOPS is quite the change, to say the least, particularly when there's no way you're CPU bound at 280K to begin with. -- Jens Axboe