Opened 15 years ago
Closed 12 years ago
#103 closed defect (worksforme)
Running some of the kernel tests leaks memory
Reported by: | Jakub Jermář | Owned by: | Jakub Jermář |
---|---|---|---|
Priority: | major | Milestone: | 0.5.0 |
Component: | helenos/kernel/generic | Version: | mainline |
Keywords: | Cc: | ||
Blocker for: | Depends on: | ||
See also: |
Description
Running some of the kernel tests such as slab2 from the kconsole leaks memory as can be shown by the zones command run before and after the test.
Change History (6)
comment:1 by , 15 years ago
Component: | unspecified → kernel/generic |
---|
comment:2 by , 15 years ago
comment:3 by , 15 years ago
Milestone: | 0.4.1 → 0.5.0 |
---|
Retargeting this for 0.5.0 in the eve of 0.4.1 release.
comment:4 by , 14 years ago
Owner: | set to |
---|---|
Status: | new → assigned |
comment:5 by , 14 years ago
Milestone: | 0.4.3 → 0.5.0 |
---|
comment:6 by , 12 years ago
Resolution: | → worksforme |
---|---|
Status: | assigned → closed |
Interestingly, the latest mainline does not exhibit this problem. I killed klog to eliminate its effect on the free memory and repeated the above tests (twice) and each time, after reclaiming the memory, I got to the initial state. The problem got probably fixed as a side effect of some other changes that went in during the past 3 years.
Note:
See TracTickets
for help on using tickets.
It may seem that in the case of the slab2 test, the memory is not released by the slab allocator as explained in the comment in slab.c. That is true, but the memory leaks even when the cached memory is reclaimed back:
1) after boot, I let the memory pressure settle so that the zones command gives the constant values; in my case this was 29249 free frames in one of the zones.
2) test slab2
3) the zones command shows only 28962 free frames
4) I run:
call1 generic/src/mm/slab.o:slab_reclaim 1
5) the zones command shows 29221 free frames, which is still 28 frames (112KiB) less than before the slab2 test