Hello, everyone
In the context of ubiquitous intelligent computing, the latency observation
capability of the operating system is particularly important, especially for
identifying severe business failures caused by occasional high-latency issues,
which are difficult to locate.
Addressing the shortcomings of existing latency observation methods, such as
getdelays, which can only be used to view average latency and does not record
abnormal latency peaks, making it difficult to identify abnormal latency situations,
I have some thoughts and contributions in the Linux Kernel regarding this point.
Here are some of my contributions :
1) delaytop contributions
Delaytop is used to observe system-wide latency top-n tasks, which helps in
locating latency-related system performance issues. [1][2]
2) latency-related contributions
I’ve also contributed to latency monitoring in the past (e.g., max latency patches),
showing a continued interest in this area. [3][4]
PS:
The list of files/directories I want to maintain is as follows:
Documentation/accounting/delay-accounting.rst
tools/accounting/*
The related patches are as follows:
[1] https://lore.kernel.org/all/20250619211843633h05gWrBDMFkEH6xAVm_5y@zte.com.…
[2] https://lore.kernel.org/all/20250710135451340_5pOgpIFi0M5AE7H44W1D@zte.com.…
[3] https://lore.kernel.org/all/20241203164848805CS62CQPQWG9GLdQj2_BxS@zte.com.…
[4] https://lore.kernel.org/all/20241220173105906EOdsPhzjMLYNJJBqgz1ga@zte.com.…
My solution has been recognized and merged into the mainline
Linux kernel, and I am currently serving as the maintainer of the
getdelays in the Linux kernel. I would like to formally apply for
the maintainer role of this module within the Anolis community as
well.
In this capacity, I aim to further enhance the latency monitoring
capabilities, synchronize the latest upstream code, participate
in code reviews, and contribute to the sustained development of
this module within the Anolis ecosystem.
Thanks
Yaxin
commit bcebe44f6bb6d9a85e0710d0086bc3956e6887ba upstream.
In some of the merge conflict fixes, one '+' was accidentally left at
the beginning of the line. Fortunately, this did not cause any major
issues since it acted as a number signal. This commit addresses this
issue by removing the extra '+'.
Acked-by: Wayne Lin <wayne.lin(a)amd.com>
Signed-off-by: Rodrigo Siqueira <Rodrigo.Siqueira(a)amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler(a)amd.com>
Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com>
(cherry picked from commit bcebe44f6bb6d9a85e0710d0086bc3956e6887ba)
Signed-off-by: Cryolitia PukNgae <cryolitia(a)uniontech.com>
---
drivers/gpu/drm/amd/display/modules/freesync/freesync.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/modules/freesync/freesync.c
b/drivers/gpu/drm/amd/display/modules/freesync/freesync.c
index 803586f4267a..c453623f376a 100644
--- a/drivers/gpu/drm/amd/display/modules/freesync/freesync.c
+++ b/drivers/gpu/drm/amd/display/modules/freesync/freesync.c
@@ -1060,7 +1060,7 @@ void mod_freesync_build_vrr_params(struct
mod_freesync *mod_freesync,
in_out_vrr->fixed_refresh_in_uhz = 0;
refresh_range = div_u64(in_out_vrr->max_refresh_in_uhz + 500000,
1000000) -
-+ div_u64(in_out_vrr->min_refresh_in_uhz + 500000, 1000000);
+ div_u64(in_out_vrr->min_refresh_in_uhz + 500000, 1000000);
in_out_vrr->supported = true;
}
--
2.50.1