From c304f43d14e98d4bf1215fc10bc5012f554bdd8a Mon Sep 17 00:00:00 2001 From: Alexandre Frade Date: Mon, 29 Jan 2018 16:59:22 +0000 Subject: [PATCH 02/17] dcache: cache_pressure = 50 decreases the rate at which VFS caches are reclaimed Signed-off-by: Alexandre Frade --- fs/dcache.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/dcache.c b/fs/dcache.c index 361ea7ab30ea..0c5cf69b241a 100644 --- a/fs/dcache.c +++ b/fs/dcache.c @@ -71,7 +71,7 @@ * If no ancestor relationship: * arbitrary, since it's serialized on rename_lock */ -int sysctl_vfs_cache_pressure __read_mostly = 100; +int sysctl_vfs_cache_pressure __read_mostly = 50; EXPORT_SYMBOL_GPL(sysctl_vfs_cache_pressure); __cacheline_aligned_in_smp DEFINE_SEQLOCK(rename_lock); -- 2.28.0 diff --git a/kernel/sched/rt.c b/kernel/sched/rt.c index f788cd61df21..2bfbb4213707 100644 --- a/kernel/sched/rt.c +++ b/kernel/sched/rt.c @@ -20,9 +20,9 @@ /* * part of the period that we allow rt tasks to run in us. - * default: 0.95s + * XanMod default: 0.98s */ -int sysctl_sched_rt_runtime = 950000; +int sysctl_sched_rt_runtime = 980000; #ifdef CONFIG_SYSCTL static int sysctl_sched_rr_timeslice = (MSEC_PER_SEC * RR_TIMESLICE) / HZ; -- 2.28.0 From f85ed068b4d0e6c31edce8574a95757a60e58b87 Mon Sep 17 00:00:00 2001 From: Etienne Juvigny Date: Mon, 3 Sep 2018 17:36:25 +0200 Subject: [PATCH 07/17] Add Zenify option --- init/Kconfig | 32 ++++++++++++++++++++++++++++++++ 3 files changed, 65 insertions(+) diff --git a/init/Kconfig b/init/Kconfig index 3ae8678e1145..da708eed0f1e 100644 --- a/init/Kconfig +++ b/init/Kconfig @@ -92,6 +92,38 @@ config THREAD_INFO_IN_TASK menu "General setup" +config ZENIFY + bool "A selection of patches from Zen/Liquorix kernel and additional tweaks for a better gaming experience" + default y + help + Tunes the kernel for responsiveness at the cost of throughput and power usage. + + --- Virtual Memory Subsystem --------------------------- + + Mem dirty before bg writeback..: 10 % -> 20 % + Mem dirty before sync writeback: 20 % -> 50 % + + --- Block Layer ---------------------------------------- + + Queue depth...............: 128 -> 512 + Default MQ scheduler......: mq-deadline -> bfq + + --- CFS CPU Scheduler ---------------------------------- + + Scheduling latency.............: 6 -> 3 ms + Minimal granularity............: 0.75 -> 0.3 ms + Wakeup granularity.............: 1 -> 0.5 ms + CPU migration cost.............: 0.5 -> 0.25 ms + Bandwidth slice size...........: 5 -> 3 ms + Ondemand fine upscaling limit..: 95 % -> 85 % + + --- MuQSS CPU Scheduler -------------------------------- + + Scheduling interval............: 6 -> 3 ms + ISO task max realtime use......: 70 % -> 25 % + Ondemand coarse upscaling limit: 80 % -> 45 % + Ondemand fine upscaling limit..: 95 % -> 45 % + config BROKEN bool -- 2.28.0 From e92e67143385cf285851e12aa8b7f083dd38dd24 Mon Sep 17 00:00:00 2001 From: Steven Barrett Date: Sun, 16 Jan 2011 18:57:32 -0600 Subject: [PATCH 08/17] ZEN: Allow TCP YeAH as default congestion control 4.4: In my tests YeAH dramatically slowed down transfers over a WLAN, reducing throughput from ~65Mbps (CUBIC) to ~7MBps (YeAH) over 10 seconds (netperf TCP_STREAM) including long stalls. Be careful when choosing this. ~heftig --- net/ipv4/Kconfig | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/net/ipv4/Kconfig b/net/ipv4/Kconfig index e64e59b536d3..bfb55ef7ebbe 100644 --- a/net/ipv4/Kconfig +++ b/net/ipv4/Kconfig @@ -691,6 +691,9 @@ choice config DEFAULT_VEGAS bool "Vegas" if TCP_CONG_VEGAS=y + config DEFAULT_YEAH + bool "YeAH" if TCP_CONG_YEAH=y + config DEFAULT_VENO bool "Veno" if TCP_CONG_VENO=y @@ -724,6 +727,7 @@ config DEFAULT_TCP_CONG default "htcp" if DEFAULT_HTCP default "hybla" if DEFAULT_HYBLA default "vegas" if DEFAULT_VEGAS + default "yeah" if DEFAULT_YEAH default "westwood" if DEFAULT_WESTWOOD default "veno" if DEFAULT_VENO default "reno" if DEFAULT_RENO -- 2.28.0 From 76dbe7477bfde1b5e8bf29a71b5af7ab2be9b98e Mon Sep 17 00:00:00 2001 From: Steven Barrett Date: Wed, 28 Nov 2018 19:01:27 -0600 Subject: [PATCH 09/17] zen: Use [defer+madvise] as default khugepaged defrag strategy For some reason, the default strategy to respond to THP fault fallbacks is still just madvise, meaning stall if the program wants transparent hugepages, but don't trigger a background reclaim / compaction if THP begins to fail allocations. This creates a snowball affect where we still use the THP code paths, but we almost always fail once a system has been active and busy for a while. The option "defer" was created for interactive systems where THP can still improve performance. If we have to fallback to a regular page due to an allocation failure or anything else, we will trigger a background reclaim and compaction so future THP attempts succeed and previous attempts eventually have their smaller pages combined without stalling running applications. We still want madvise to stall applications that explicitely want THP, so defer+madvise _does_ make a ton of sense. Make it the default for interactive systems, especially if the kernel maintainer left transparent hugepages on "always". Reasoning and details in the original patch: https://lwn.net/Articles/711248/ --- mm/huge_memory.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/mm/huge_memory.c b/mm/huge_memory.c index 74300e337c3c..9277f22c10a7 100644 --- a/mm/huge_memory.c +++ b/mm/huge_memory.c @@ -53,7 +53,11 @@ unsigned long transparent_hugepage_flags __read_mostly = #ifdef CONFIG_TRANSPARENT_HUGEPAGE_MADVISE (1< Date: Wed, 24 Oct 2018 16:58:52 -0300 Subject: [PATCH 10/17] net/sched: allow configuring cake qdisc as default Signed-off-by: Alexandre Frade --- net/sched/Kconfig | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/net/sched/Kconfig b/net/sched/Kconfig index 84badf00647e..6a922bca9f39 100644 --- a/net/sched/Kconfig +++ b/net/sched/Kconfig @@ -471,6 +471,9 @@ choice config DEFAULT_SFQ bool "Stochastic Fair Queue" if NET_SCH_SFQ + config DEFAULT_CAKE + bool "Common Applications Kept Enhanced" if NET_SCH_CAKE + config DEFAULT_PFIFO_FAST bool "Priority FIFO Fast" endchoice @@ -488,6 +488,7 @@ default "fq_codel" if DEFAULT_FQ_CODEL default "fq_pie" if DEFAULT_FQ_PIE default "sfq" if DEFAULT_SFQ + default "cake" if DEFAULT_CAKE default "pfifo_fast" endif -- 2.28.0 From 90240bcd90a568878738e66c0d45bed3e38e347b Mon Sep 17 00:00:00 2001 From: Tk-Glitch Date: Fri, 19 Apr 2019 12:33:38 +0200 Subject: [PATCH 12/17] Set vm.max_map_count to 262144 by default The value is still pretty low, and AMD64-ABI and ELF extended numbering supports that, so we should be fine on modern x86 systems. This fixes crashes in some applications using more than 65535 vmas (also affects some windows games running in wine, such as Star Citizen). --- include/linux/mm.h | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/include/linux/mm.h b/include/linux/mm.h index bc05c3588aa3..b0cefe94920d 100644 --- a/include/linux/mm.h +++ b/include/linux/mm.h @@ -190,8 +190,7 @@ static inline void __mm_zero_struct_page(struct page *page) * not a hard limit any more. Although some userspace tools can be surprised by * that. */ -#define MAPCOUNT_ELF_CORE_MARGIN (5) -#define DEFAULT_MAX_MAP_COUNT (USHRT_MAX - MAPCOUNT_ELF_CORE_MARGIN) +#define DEFAULT_MAX_MAP_COUNT (262144) extern int sysctl_max_map_count; -- 2.28.0 From 3a34034dba5efe91bcec491efe8c66e8087f509b Mon Sep 17 00:00:00 2001 From: Tk-Glitch Date: Mon, 27 Jul 2020 00:19:18 +0200 Subject: [PATCH 13/17] mm: bump DEFAULT_MAX_MAP_COUNT Some games such as Detroit: Become Human tend to be very crash prone with lower values. --- include/linux/mm.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/linux/mm.h b/include/linux/mm.h index b0cefe94920d..890165099b07 100644 --- a/include/linux/mm.h +++ b/include/linux/mm.h @@ -190,7 +190,7 @@ static inline void __mm_zero_struct_page(struct page *page) * not a hard limit any more. Although some userspace tools can be surprised by * that. */ -#define DEFAULT_MAX_MAP_COUNT (262144) +#define DEFAULT_MAX_MAP_COUNT (16777216) extern int sysctl_max_map_count; -- 2.28.0 From 977812938da7c7226415778c340832141d9278b7 Mon Sep 17 00:00:00 2001 From: Alexandre Frade Date: Mon, 25 Nov 2019 15:13:06 -0300 Subject: [PATCH 14/17] elevator: set default scheduler to bfq for blk-mq Signed-off-by: Alexandre Frade --- block/elevator.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/block/elevator.c b/block/elevator.c index 4eab3d70e880..79669aa39d79 100644 --- a/block/elevator.c +++ b/block/elevator.c @@ -561,8 +561,8 @@ } /* - * For single queue devices, default to using mq-deadline. If we have multiple - * queues or mq-deadline is not available, default to "none". + * For single queue devices, default to using bfq. If we have multiple + * queues or bfq is not available, default to "none". */ static struct elevator_type *elevator_get_default(struct request_queue *q) { @@ -573,7 +573,7 @@ !blk_mq_is_shared_tags(q->tag_set->flags)) return NULL; - return elevator_find_get(q, "mq-deadline"); + return elevator_find_get(q, "bfq"); } /* -- 2.28.0 From 3c229f434aca65c4ca61772bc03c3e0370817b92 Mon Sep 17 00:00:00 2001 From: Alexandre Frade Date: Mon, 3 Aug 2020 17:05:04 +0000 Subject: [PATCH 16/17] mm: set 2 megabytes for address_space-level file read-ahead pages size Signed-off-by: Alexandre Frade --- include/linux/pagemap.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/linux/pagemap.h b/include/linux/pagemap.h index cf2468da68e9..007dea784451 100644 --- a/include/linux/pagemap.h +++ b/include/linux/pagemap.h @@ -851,7 +851,7 @@ ._index = i, \ } -#define VM_READAHEAD_PAGES (SZ_128K / PAGE_SIZE) +#define VM_READAHEAD_PAGES (SZ_2M / PAGE_SIZE) void page_cache_ra_unbounded(struct readahead_control *, unsigned long nr_to_read, unsigned long lookahead_count); -- 2.28.0 From 716f41cf6631f3a85834dcb67b4ce99185b6387f Mon Sep 17 00:00:00 2001 From: Steven Barrett Date: Wed, 15 Jan 2020 20:43:56 -0600 Subject: [PATCH 17/17] ZEN: intel-pstate: Implement "enable" parameter If intel-pstate is compiled into the kernel, it will preempt the loading of acpi-cpufreq so you can take advantage of hardware p-states without any friction. However, intel-pstate is not completely superior to cpufreq's ondemand for one reason. There's no concept of an up_threshold property. In ondemand, up_threshold essentially reduces the maximum utilization to compare against, allowing you to hit max frequencies and turbo boost from a much lower core utilization. With intel-pstate, you have the concept of minimum and maximum performance, but no tunable that lets you define, maximum frequency means 50% core utilization. For just this oversight, there's reasons you may want ondemand. Lets support setting "enable" in kernel boot parameters. This lets kernel maintainers include "intel_pstate=disable" statically in the static boot parameters, but let users of the kernel override this selection. --- Documentation/admin-guide/kernel-parameters.txt | 3 +++ drivers/cpufreq/intel_pstate.c | 2 ++ 2 files changed, 5 insertions(+) diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index fb95fad81c79..3e92fee81e33 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -2133,6 +2133,9 @@ disable Do not enable intel_pstate as the default scaling driver for the supported processors + enable + Enable intel_pstate in-case "disable" was passed + previously in the kernel boot parameters active Use intel_pstate driver to bypass the scaling governors layer of cpufreq and provides it own diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c index 36a469150ff9..aee891c9b78a 100644 --- a/drivers/cpufreq/intel_pstate.c +++ b/drivers/cpufreq/intel_pstate.c @@ -3510,6 +3510,8 @@ if (!strcmp(str, "no_hwp")) no_hwp = 1; + if (!strcmp(str, "enable")) + no_load = 0; if (!strcmp(str, "force")) force_load = 1; if (!strcmp(str, "hwp_only")) -- 2.28.0 From 379cbab18b5c75c622b93e2c5abdfac141fe9654 Mon Sep 17 00:00:00 2001 From: Kenny Levinsen Date: Sun, 27 Dec 2020 14:43:13 +0000 Subject: [PATCH] ZEN: Input: evdev - use call_rcu when detaching client Significant time was spent on synchronize_rcu in evdev_detach_client when applications closed evdev devices. Switching VT away from a graphical environment commonly leads to mass input device closures, which could lead to noticable delays on systems with many input devices. Replace synchronize_rcu with call_rcu, deferring reclaim of the evdev client struct till after the RCU grace period instead of blocking the calling application. While this does not solve all slow evdev fd closures, it takes care of a good portion of them, including this simple test: #include #include int main(int argc, char *argv[]) { int idx, fd; const char *path = "/dev/input/event0"; for (idx = 0; idx < 1000; idx++) { if ((fd = open(path, O_RDWR)) == -1) { return -1; } close(fd); } return 0; } Time to completion of above test when run locally: Before: 0m27.111s After: 0m0.018s Signed-off-by: Kenny Levinsen --- drivers/input/evdev.c | 19 +++++++++++-------- 1 file changed, 11 insertions(+), 8 deletions(-) diff --git a/drivers/input/evdev.c b/drivers/input/evdev.c index 95f90699d2b17b..2b10fe29d2c8d9 100644 --- a/drivers/input/evdev.c +++ b/drivers/input/evdev.c @@ -46,6 +46,7 @@ struct evdev_client { struct fasync_struct *fasync; struct evdev *evdev; struct list_head node; + struct rcu_head rcu; enum input_clock_type clk_type; bool revoked; unsigned long *evmasks[EV_CNT]; @@ -377,13 +378,22 @@ static void evdev_attach_client(struct evdev *evdev, spin_unlock(&evdev->client_lock); } +static void evdev_reclaim_client(struct rcu_head *rp) +{ + struct evdev_client *client = container_of(rp, struct evdev_client, rcu); + unsigned int i; + for (i = 0; i < EV_CNT; ++i) + bitmap_free(client->evmasks[i]); + kvfree(client); +} + static void evdev_detach_client(struct evdev *evdev, struct evdev_client *client) { spin_lock(&evdev->client_lock); list_del_rcu(&client->node); spin_unlock(&evdev->client_lock); - synchronize_rcu(); + call_rcu(&client->rcu, evdev_reclaim_client); } static int evdev_open_device(struct evdev *evdev) @@ -436,7 +446,6 @@ static int evdev_release(struct inode *inode, struct file *file) { struct evdev_client *client = file->private_data; struct evdev *evdev = client->evdev; - unsigned int i; mutex_lock(&evdev->mutex); @@ -448,11 +457,6 @@ static int evdev_release(struct inode *inode, struct file *file) evdev_detach_client(evdev, client); - for (i = 0; i < EV_CNT; ++i) - bitmap_free(client->evmasks[i]); - - kvfree(client); - evdev_close_device(evdev); return 0; @@ -495,7 +499,6 @@ static int evdev_open(struct inode *inode, struct file *file) err_free_client: evdev_detach_client(evdev, client); - kvfree(client); return error; } From 2aafb56f20e4b63d8c4af172fe9d017c64bc4129 Mon Sep 17 00:00:00 2001 From: Sultan Alsawaf Date: Wed, 20 Oct 2021 20:50:11 -0700 Subject: [PATCH] ZEN: mm: Lower the non-hugetlbpage pageblock size to reduce scheduling delays The page allocator processes free pages in groups of pageblocks, where the size of a pageblock is typically quite large (1024 pages without hugetlbpage support). Pageblocks are processed atomically with the zone lock held, which can cause severe scheduling delays on both the CPU going through the pageblock and any other CPUs waiting to acquire the zone lock. A frequent offender is move_freepages_block(), which is used by rmqueue() for page allocation. As it turns out, there's no requirement for pageblocks to be so large, so the pageblock order can simply be reduced to ease the scheduling delays and zone lock contention. PAGE_ALLOC_COSTLY_ORDER is used as a reasonable setting to ensure non-costly page allocation requests can still be serviced without always needing to free up more than one pageblock's worth of pages at a time. This has a noticeable effect on overall system latency when memory pressure is elevated. The various mm functions which operate on pageblocks no longer appear in the preemptoff tracer, where previously they would spend up to 100 ms on a mobile arm64 CPU processing a pageblock with preemption disabled and the zone lock held. Signed-off-by: Sultan Alsawaf --- include/linux/pageblock-flags.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/linux/pageblock-flags.h b/include/linux/pageblock-flags.h index 5f1ae07d724b88..97cda629c9e909 100644 --- a/include/linux/pageblock-flags.h +++ b/include/linux/pageblock-flags.h @@ -48,7 +48,7 @@ extern unsigned int pageblock_order; #else /* CONFIG_HUGETLB_PAGE */ /* If huge pages are not used, group by MAX_ORDER_NR_PAGES */ -#define pageblock_order MAX_ORDER +#define pageblock_order PAGE_ALLOC_COSTLY_ORDER #endif /* CONFIG_HUGETLB_PAGE */