June 2024 - kernelnewbies@kernelnewbies.org - Kernelnewbies Mailing Lists

sanity check typo patch "quired"
by daniel watson July 1, 2024

July 1, 2024

here's a patch to fix a typo in the memory management docs. i'm sending to this mailing list first for a sanity check. From: Daniel Watson <ozzloy(a)each.do> To: Jonathan Corbet <corbet(a)lwn.net>,linux-doc@vger.kernel.org,linux-kernel@vger.kernel.org Date: Wed, 26 Jun 2024 21:18:22 -0700 Subject: [PATCH] mm: docs: correct 'quired' to 'queried' Convert from the word "quired" to the word "queried" which makes more sense in this context. Signed-off-by: Daniel Watson <ozzloy(a)each.do> --- Documentation/admin-guide/mm/index.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/admin-guide/mm/index.rst b/Documentation/admin-guide/mm/index.rst index 1f883abf3f00f..8b35795b664be 100644 --- a/Documentation/admin-guide/mm/index.rst +++ b/Documentation/admin-guide/mm/index.rst @@ -10,7 +10,7 @@ processes address space and many other cool things. Linux memory management is a complex system with many configurable settings. Most of these settings are available via ``/proc`` -filesystem and can be quired and adjusted using ``sysctl``. These APIs +filesystem and can be queried and adjusted using ``sysctl``. These APIs are described in Documentation/admin-guide/sysctl/vm.rst and in `man 5 proc`_. .. _man 5 proc: http://man7.org/linux/man-pages/man5/proc.5.html -- 2.43.0

2 2

RISC-V and interrupts, constant rate vs. tickless vs. SIE=0
by Andras Pal June 28, 2024

June 28, 2024

Hi All, I'm compiling and installing the RISC-V (RV32IMAC) port of Linux to a custom FPGA-based SoC. However, during the ISA level simulations, there is an indication that do_idle() disables the supervisor interrupts by setting SIE=0 in the CSR sstatus, just before entering to WFI state. It happens right after starting the /init process from initrd, so when the (presumably) first U mode precess is executed and this process is just waiting from interrupts from the console (that is a 8250/16550, connected to SEI via PLIC). I tried both tickless and constant rate timers in Config > General setup > Timers subsystem, but both of them behaves the same. If the system is tickless, it might make sense to disable STIE in the CSR sie, but not SIE in sstatus... How can this issue be debugged or checked in more details, do you have any recommendations where to start? The kernel version is one of the most recent longterm one (6.6.32, to be precise). thanks in advance, Andras

1 0

Re: How to accout max_rss precisely
by Heran Yang June 17, 2024

June 17, 2024

Hi, and thanks for your reply. I totally forgot to take the dynamic loader into consideration, which is my bad. But another problem is that the peak value cannot align with the max_rss getting from `getrusage` function, which is ~1000KiB. I guess that it has some connection with max_rss inheriting, but I'm not sure about that. Do you have any opinion about it? 杨贺然 <herany1999(a)gmail.com> 于2024年6月4日周二 21:37写道： > Hi, and thanks for your reply. I totally forgot to take the dynamic loader > into consideration, which is my bad. > > But another problem is that the peak value cannot align with the max_rss > getting from `getrusage` function, which > is ~1000KiB. I guess that it has some connection with max_rss inheriting, > but I'm not sure about that. Do you have > any opinion about it? > > Valdis Klētnieks <valdis.kletnieks(a)vt.edu> 于2024年6月4日周二 01:44写道： > >> On Sat, 01 Jun 2024 15:01:32 +0800, 杨贺然 said: >> >> > // a.c >> > int main() {} >> > >> > It shows that `memory.peak` of this program is ~500KiB, which does not >> make >> > sense to me. >> >> Makes sense to me... >> >> [~] cat > testnull.c >> int main() {} >> [~] gcc testnull.c >> [~] ldd a.out >> linux-vdso.so.1 (0x00007efc6a650000) >> libc.so.6 => /lib64/libc.so.6 (0x00007efc6a43d000) >> /lib64/ld-linux-x86-64.so.2 (0x00007efc6a652000) >> [~] objdump -d a.out >> >> a.out: file format elf64-x86-64 >> >> >> Disassembly of section .init: >> >> 0000000000401000 <_init>: >> 401000: f3 0f 1e fa endbr64 >> 401004: 48 83 ec 08 sub $0x8,%rsp >> 401008: 48 8b 05 d1 2f 00 00 mov 0x2fd1(%rip),%rax # >> 403fe0 <__gmon_start__@Base> >> 40100f: 48 85 c0 test %rax,%rax >> 401012: 74 02 je 401016 <_init+0x16> >> 401014: ff d0 call *%rax >> 401016: 48 83 c4 08 add $0x8,%rsp >> 40101a: c3 ret >> >> Disassembly of section .text: >> >> 0000000000401020 <_start>: >> 401020: f3 0f 1e fa endbr64 >> 401024: 31 ed xor %ebp,%ebp >> 401026: 49 89 d1 mov %rdx,%r9 >> 401029: 5e pop %rsi >> 40102a: 48 89 e2 mov %rsp,%rdx >> 40102d: 48 83 e4 f0 and $0xfffffffffffffff0,%rsp >> 401031: 50 push %rax >> 401032: 54 push %rsp >> 401033: 45 31 c0 xor %r8d,%r8d >> 401036: 31 c9 xor %ecx,%ecx >> 401038: 48 c7 c7 06 11 40 00 mov $0x401106,%rdi >> 40103f: ff 15 93 2f 00 00 call *0x2f93(%rip) # >> 403fd8 <__libc_start_main@GLIBC_2.34> >> 401045: f4 hlt >> 401046: 66 2e 0f 1f 84 00 00 cs nopw 0x0(%rax,%rax,1) >> 40104d: 00 00 00 >> (.....) >> >> Basically, its not *really* a totally null program. You've got the >> dynamic >> loader ld-linux running first, which then *doesn't* run main() directly, >> but >> rather invokes _start, which needs to happen so that __libc_start_main >> can get >> called and initialize stuff lie stdio, malloc, and other such t hings, >> before >> it finally calls main(). >> >> Personally, I'm surprised that ld-linux and glibc initialization can >> finish >> without going over 500k - even more so if shared library text pages are >> included in memory.peak. Somebody else can wade into that mess, I admit >> having been around since kernel 2.5.47 or so, and I never did understand >> the >> memory accounting for shared text pages.... >> >>

2 2

DMA Engine - dealing with timeouts
by Anthony Clark June 10, 2024

June 10, 2024

Hey all, As a newbie, I'm trying to figure out how to properly deal with timeouts for dma_engine_submit(). I'm using a """prototype""" kernel module that sits on-tops of the Xilinx AXIDMA driver as part of Xilinx's Linux fork. They do a good job of merging with upstream kernels but there are some Xilinx-specific things and I apologize if some information is hard to parse. I believe my question is generic to the DMA Engine framework. This module, called "dma-proxy" is discussed a lot by Xilinx forums members but information doesn't typically flow back to users where there are fixes. Aside from the "dma-proxy" driver, Xilinx also includes a "AXIDMA Test" driver. Both drivers sit atop of the Xilinx DMA driver and do various things. The "dma-proxy" does some sharing of memory between userspace and the kernel but that's not really important to my question. First, this chain eventually resolves into `dma_engine_submit()`: ----------------------------------------------------------------- (~ https://github.com/Xilinx-Wiki-Projects/software-prototypes/blob/master/lin… ) sg_init_table(..., 1); sg_dma_address(... ) = foo.dma_handle; sg_dma_len(...t) = foo.length; chan_desc = dma_device->device_prep_slave_sg(..., ..., 1, ..., ..., NULL); if (! chan_desc) { printk(KERN_ERR "dmaengine_prep*() error\n"); else { ... } Then, the driver waits for the completion and prints an error if it cannot complete: ------------------------------------------------------------------------------------------------------------------- unsigned long timeout = msecs_to_jiffies(3000); timeout = wait_for_completion_timeout(foo.cmp, timeout); status = dma_async_is_tx_complete(..., ..., NULL, NULL); if (timeout == 0) { printk(KERN_ERR "DMA timed out\n"); } else { ... } ====== I cannot figure out what to do in the case of a timeout. It appears descriptors (chan_desc) are being leaked when completion cannot be completed. I see some patches to make the list of descriptors larger but it appears the default/configured is 255. So if I sit and timeout for 3sec * 255, I run out of descriptors and that DMA engine instance is no longer usable. It appears that even Xilinx's AXIDMA Test driver doesn't handle any sort of resource release or cleanup either: https://github.com/Xilinx/linux-xlnx/blob/master/drivers/dma/xilinx/axidmat… I hope someone can point me in the right direction so I can timeout nicely. Thanks! -- Anthony G. Clark Gtalk :: clark.anthony.g Phone :: 951 526 5237

1 0

How to accout max_rss precisely
by 杨贺然 June 3, 2024

June 3, 2024

Hi, I'm working on a utility to report the maximum memory usage of a certain program. I intend to show the max_rss of this process and its children, but it's hard to use getrusage to get the RSS precisely, so I'm trying to leverage cgroups. However on the document of cgroups v2, `memory.peak` says: The max memory usage recorded for the cgroup and its descendants since the creation of the cgroup. It didn't explain the composition of memory usage. So I want to ask that is the memory usage in `memory.peak` the maximum of RSS? I made a quick test on an empty program like: ```c // a.c int main() {} ``` It shows that `memory.peak` of this program is ~500KiB, which does not make sense to me. I also wonder how to implement the same function under OS without cgroups, like BSD and macOS. Thanks

2 1

Memory reclaim mechanisms freezing system
by Yeongjin Kwon June 3, 2024

June 3, 2024

Hello, I have been using GNU/Linux as my daily driver for 3 years. During that whole time, I have experienced this problem where my system would often freeze up and become unresponsive for a few seconds here and there when it is under load, which has been a big pain. After experimenting and trying to find the cause of the problem, I now suspect the root cause is that the kernel memory reclaim mechanisms (kswapd, direct reclaim, etc.) use too much CPU time, not allowing my desktop environment processes to run. My computer is a Surface Pro (1st Gen). Here is a link to its specifications: https://support.microsoft.com/en-us/surface/surface-pro-1st-gen-specificati… Notably, my computer has 4GB of ram and 8 GB of swap. I am currently using the sway tiling window manager on arch linux, but have also experienced the freezing problem on KDE plasma, gnome, and other linux distros. There is some configuration I changed from the defaults to improve performance. I turned zswap off, and set the vm.page-cluster sysctl to 3 (which might have been the default anyways). There are several reasons I did this, but I will not expand on them here. My system generally freezes when it has low free memory, is using swap, and I switch to an application that has not been recently active. The problem gets worse when more swap is being used. When my system is using around 3-4 GB or more of swap, it even stalls for tens of seconds. And so I believe the problem occurs when my system is swapping a lot. I thought the freezing was due to my desktop processes getting swapped out, so I allocated memory, cpu, and io bandwidth protections using cgroups and systemd to my desktop/system processes so that they would not get swapped out and that they would have enough resources even under load. This significantly helped solve the freezing, but the problem still remained. As I understand it, there are two procedures involved in swapping when free memory is low, which are reading data into memory from swap when page faults occur, and swapping old data out of memory onto disk (reclaiming memory) to make room for the data being swapped in. Furthermore, I have observed the system freezing when it exhausts available ram and starts swapping memory out onto disk, even when there is no swap usage at the time. This leads me to believe the freezing is caused by the latter of the two procedures, memory reclamation. In addition, I did not observe the problem occurring when the system was swapping data in from disk while there was plenty of free memory. I also recently tried increasing the vm.watermark_scale_factor sysctl parameter. When I did, the freezing problem became worse. According to the documentation, this sysctl parameter is used to tune the aggressiveness of kswapd. Assuming kswapd is more aggressive and active the higher the parameter is, the amount of activity of kswapd would be positively correlated with the severity of the problem. I also tried using the linux zen kernel, but that did not seem to alleviate the problem, and I believe it actually made performance worse. And so now I think it's possible that the kernel memory reclaim mechanisms are using up too much CPU and ignoring the cpu protections (cpu.weight parameter) that I set for my desktop environment processes. It explains why my system freezes even though I allocated protections to my desktop environment. The kernel can just bypass them all. I know all the details I mentioned above may be vague and unreliable as evidence. I suppose it might be faster and more accurate to do some profiling, but I unfortunately do not know how to go about profiling my system. Is my suspicion correct? If so, is there any way to restrict the CPU time these reclaim mechanisms get? Will doing that be likely to improve performance? Perhaps this occurs because the reclaim mechanisms do not yield the CPU at all until the respective watermark is reached. If this is the case, is anyone working to make these mechanisms more preemptible and less CPU hogging? I would love to try implementing these changes myself, but at the moment, I unfortunately have no experience in kernel hacking. I thought it might be a good idea to post a question and see if anyone else has some more insight into the issue, before attempting further experimentation. Thank you for your time. Yeongjin Kwon

1 0