release 6.12.4 (preliminary)
This commit is contained in:
@@ -11,7 +11,7 @@ avoid having to enable `CONFIG_EXPERT`.
|
||||
|
||||
--- a/arch/Kconfig
|
||||
+++ b/arch/Kconfig
|
||||
@@ -1050,7 +1050,7 @@ config ARCH_MMAP_RND_BITS
|
||||
@@ -1089,7 +1089,7 @@ config ARCH_MMAP_RND_BITS
|
||||
int "Number of bits to use for ASLR of mmap base address" if EXPERT
|
||||
range ARCH_MMAP_RND_BITS_MIN ARCH_MMAP_RND_BITS_MAX
|
||||
default ARCH_MMAP_RND_BITS_DEFAULT if ARCH_MMAP_RND_BITS_DEFAULT
|
||||
@@ -20,7 +20,7 @@ avoid having to enable `CONFIG_EXPERT`.
|
||||
depends on HAVE_ARCH_MMAP_RND_BITS
|
||||
help
|
||||
This value can be used to select the number of bits to use to
|
||||
@@ -1084,7 +1084,7 @@ config ARCH_MMAP_RND_COMPAT_BITS
|
||||
@@ -1123,7 +1123,7 @@ config ARCH_MMAP_RND_COMPAT_BITS
|
||||
int "Number of bits to use for ASLR of mmap base address for compatible applications" if EXPERT
|
||||
range ARCH_MMAP_RND_COMPAT_BITS_MIN ARCH_MMAP_RND_COMPAT_BITS_MAX
|
||||
default ARCH_MMAP_RND_COMPAT_BITS_DEFAULT if ARCH_MMAP_RND_COMPAT_BITS_DEFAULT
|
||||
|
||||
@@ -1,112 +0,0 @@
|
||||
From b7d96c1f19ef15ea431a8d5d7ab2cad22c35edba Mon Sep 17 00:00:00 2001
|
||||
From: Qais Yousef <qyousef@layalina.io>
|
||||
Date: Sun, 28 Jul 2024 20:26:59 +0100
|
||||
Subject: cpufreq: Remove LATENCY_MULTIPLIER
|
||||
|
||||
The current LATENCY_MULTIPLIER which has been around for nearly 20 years
|
||||
causes rate_limit_us to be always in ms range.
|
||||
|
||||
On M1 mac mini I get 50 and 56us transition latency, but due to the 1000
|
||||
multiplier we end up setting rate_limit_us to 50 and 56ms, which gets
|
||||
capped into 2ms and was 10ms before e13aa799c2a6 ("cpufreq: Change
|
||||
default transition delay to 2ms")
|
||||
|
||||
On Intel I5 system transition latency is 20us but due to the multiplier
|
||||
we end up with 20ms that again is capped to 2ms.
|
||||
|
||||
Given how good modern hardware and how modern workloads require systems
|
||||
to be more responsive to cater for sudden changes in workload (tasks
|
||||
sleeping/wakeup/migrating, uclamp causing a sudden boost or cap) and
|
||||
that 2ms is quarter of the time of 120Hz refresh rate system, drop the
|
||||
old logic in favour of providing 50% headroom.
|
||||
|
||||
rate_limit_us = 1.5 * latency.
|
||||
|
||||
I considered not adding any headroom which could mean that we can end up
|
||||
with infinite back-to-back requests.
|
||||
|
||||
I also considered providing a constant headroom (e.g: 100us) assuming
|
||||
that any h/w or f/w dealing with the request shouldn't require a large
|
||||
headroom when transition_latency is actually high.
|
||||
|
||||
But for both cases I wasn't sure if h/w or f/w can end up being
|
||||
overwhelmed dealing with the freq requests in a potentially busy system.
|
||||
So I opted for providing 50% breathing room.
|
||||
|
||||
This is expected to impact schedutil only as the other user,
|
||||
dbs_governor, takes the max(2*tick, transition_delay_us) and the former
|
||||
was at least 2ms on 1ms TICK, which is equivalent to the max_delay_us
|
||||
before applying this patch. For systems with TICK of 4ms, this value
|
||||
would have almost always ended up with 8ms sampling rate.
|
||||
|
||||
For systems that report 0 transition latency, we still default to
|
||||
returning 1ms as transition delay.
|
||||
|
||||
This helps in eliminating a source of latency for applying requests as
|
||||
mentioned in [1]. For example if we have a 1ms tick, most systems will
|
||||
miss sending an update at tick when updating the util_avg for a task/CPU
|
||||
(rate_limit_us will be 2ms for most systems).
|
||||
|
||||
Link: https://lore.kernel.org/lkml/20240724212255.mfr2ybiv2j2uqek7@airbuntu/ # [1]
|
||||
Link: https://lore.kernel.org/lkml/20240205022500.2232124-1-qyousef@layalina.io/
|
||||
Signed-off-by: Qais Yousef <qyousef@layalina.io>
|
||||
Link: https://patch.msgid.link/20240728192659.58115-1-qyousef@layalina.io
|
||||
[ rjw: Subject edits ]
|
||||
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
||||
---
|
||||
drivers/cpufreq/cpufreq.c | 27 ++++-----------------------
|
||||
include/linux/cpufreq.h | 6 ------
|
||||
2 files changed, 4 insertions(+), 29 deletions(-)
|
||||
|
||||
--- a/drivers/cpufreq/cpufreq.c
|
||||
+++ b/drivers/cpufreq/cpufreq.c
|
||||
@@ -575,30 +575,11 @@ unsigned int cpufreq_policy_transition_d
|
||||
return policy->transition_delay_us;
|
||||
|
||||
latency = policy->cpuinfo.transition_latency / NSEC_PER_USEC;
|
||||
- if (latency) {
|
||||
- unsigned int max_delay_us = 2 * MSEC_PER_SEC;
|
||||
+ if (latency)
|
||||
+ /* Give a 50% breathing room between updates */
|
||||
+ return latency + (latency >> 1);
|
||||
|
||||
- /*
|
||||
- * If the platform already has high transition_latency, use it
|
||||
- * as-is.
|
||||
- */
|
||||
- if (latency > max_delay_us)
|
||||
- return latency;
|
||||
-
|
||||
- /*
|
||||
- * For platforms that can change the frequency very fast (< 2
|
||||
- * us), the above formula gives a decent transition delay. But
|
||||
- * for platforms where transition_latency is in milliseconds, it
|
||||
- * ends up giving unrealistic values.
|
||||
- *
|
||||
- * Cap the default transition delay to 2 ms, which seems to be
|
||||
- * a reasonable amount of time after which we should reevaluate
|
||||
- * the frequency.
|
||||
- */
|
||||
- return min(latency * LATENCY_MULTIPLIER, max_delay_us);
|
||||
- }
|
||||
-
|
||||
- return LATENCY_MULTIPLIER;
|
||||
+ return USEC_PER_MSEC;
|
||||
}
|
||||
EXPORT_SYMBOL_GPL(cpufreq_policy_transition_delay_us);
|
||||
|
||||
--- a/include/linux/cpufreq.h
|
||||
+++ b/include/linux/cpufreq.h
|
||||
@@ -577,12 +577,6 @@ static inline unsigned long cpufreq_scal
|
||||
#define CPUFREQ_POLICY_POWERSAVE (1)
|
||||
#define CPUFREQ_POLICY_PERFORMANCE (2)
|
||||
|
||||
-/*
|
||||
- * The polling frequency depends on the capability of the processor. Default
|
||||
- * polling frequency is 1000 times the transition latency of the processor.
|
||||
- */
|
||||
-#define LATENCY_MULTIPLIER (1000)
|
||||
-
|
||||
struct cpufreq_governor {
|
||||
char name[CPUFREQ_NAME_LEN];
|
||||
int (*init)(struct cpufreq_policy *policy);
|
||||
@@ -1,26 +0,0 @@
|
||||
From b97d21a0aa65a6f7a7bb17bbc696b136688c96ed Mon Sep 17 00:00:00 2001
|
||||
From: Jeff Layton <jlayton@kernel.org>
|
||||
Date: Mon, 26 Aug 2024 08:50:11 -0400
|
||||
Subject: nfsd: add more info to WARN_ON_ONCE on failed callbacks
|
||||
|
||||
Currently, you get the warning and stack trace, but nothing is printed
|
||||
about the relevant error codes. Add that in.
|
||||
|
||||
Signed-off-by: Jeff Layton <jlayton@kernel.org>
|
||||
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
|
||||
---
|
||||
fs/nfsd/nfs4callback.c | 3 ++-
|
||||
1 file changed, 2 insertions(+), 1 deletion(-)
|
||||
|
||||
--- a/fs/nfsd/nfs4callback.c
|
||||
+++ b/fs/nfsd/nfs4callback.c
|
||||
@@ -1333,7 +1333,8 @@ static void nfsd4_cb_done(struct rpc_tas
|
||||
return;
|
||||
|
||||
if (cb->cb_status) {
|
||||
- WARN_ON_ONCE(task->tk_status);
|
||||
+ WARN_ONCE(task->tk_status, "cb_status=%d tk_status=%d",
|
||||
+ cb->cb_status, task->tk_status);
|
||||
task->tk_status = cb->cb_status;
|
||||
}
|
||||
|
||||
@@ -1,32 +0,0 @@
|
||||
From 8ea93b01558ea7a752e478ad25862e7441d6053a Mon Sep 17 00:00:00 2001
|
||||
From: Johannes Thumshirn <johannes.thumshirn@wdc.com>
|
||||
Date: Thu, 19 Sep 2024 12:16:38 +0200
|
||||
Subject: btrfs: also add stripe entries for NOCOW writes
|
||||
|
||||
NOCOW writes do not generate stripe_extent entries in the RAID stripe
|
||||
tree, as the RAID stripe-tree feature initially was designed with a
|
||||
zoned filesystem in mind and on a zoned filesystem, we do not allow NOCOW
|
||||
writes. But the RAID stripe-tree feature is independent from the zoned
|
||||
feature, so we must also do NOCOW writes for RAID stripe-tree filesystems.
|
||||
|
||||
Reviewed-by: Naohiro Aota <naohiro.aota@wdc.com>
|
||||
Signed-off-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
|
||||
Signed-off-by: David Sterba <dsterba@suse.com>
|
||||
---
|
||||
fs/btrfs/inode.c | 5 +++++
|
||||
1 file changed, 5 insertions(+)
|
||||
|
||||
--- a/fs/btrfs/inode.c
|
||||
+++ b/fs/btrfs/inode.c
|
||||
@@ -3087,6 +3087,11 @@ int btrfs_finish_one_ordered(struct btrf
|
||||
ret = btrfs_update_inode_fallback(trans, inode);
|
||||
if (ret) /* -ENOMEM or corruption */
|
||||
btrfs_abort_transaction(trans, ret);
|
||||
+
|
||||
+ ret = btrfs_insert_raid_extent(trans, ordered_extent);
|
||||
+ if (ret)
|
||||
+ btrfs_abort_transaction(trans, ret);
|
||||
+
|
||||
goto out;
|
||||
}
|
||||
|
||||
Reference in New Issue
Block a user