The compaction_test memory selftest introduces fragmentation in memory
and then tries to allocate as many hugepages as possible. This series
addresses some problems.
First off, correctly set the number of hugepages to zero before trying
to set a large number of them.
Now, consider a situation in which, at the start of the test, a non-zero
number of hugepages have been already set (while running the entire
selftests/mm suite, or manually by the admin). The test operates on 80%
of memory to avoid OOM-killer invocation, and because some memory is
already blocked by hugepages, it would increase the chance of OOM-killing.
Also, since mem_free used in check_compaction() is the value before we
set nr_hugepages to zero, the chance that the compaction_index will
be small is very high if the preset nr_hugepages was high, leading to a
bogus test success.
This series applies on top of the stable 6.9 kernel.
Dev Jain (2):
selftests/mm: compaction_test: Fix incorrect write of zero to
nr_hugepages
selftests/mm: compaction_test: Fix trivial test success and reduce
probability of OOM-killer invocation
tools/testing/selftests/mm/compaction_test.c | 70 ++++++++++++++------
1 file changed, 50 insertions(+), 20 deletions(-)
--
2.30.2
nr_hugepages is not set to zero because the file offset has not been reset
after read(). Fix that using lseek().
Fixes: bd67d5c15cc1 ("Test compaction of mlocked memory")
Cc: [email protected]
Signed-off-by: Dev Jain <[email protected]>
---
Merge dependency: https://lore.kernel.org/all/[email protected]/
Andrew, does it sound reasonable to have the fixes tag in the above
patch too, along with this series?
tools/testing/selftests/mm/compaction_test.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tools/testing/selftests/mm/compaction_test.c b/tools/testing/selftests/mm/compaction_test.c
index 533999b6c284..c5be395f8363 100644
--- a/tools/testing/selftests/mm/compaction_test.c
+++ b/tools/testing/selftests/mm/compaction_test.c
@@ -107,6 +107,8 @@ int check_compaction(unsigned long mem_free, unsigned int hugepage_size)
goto close_fd;
}
+ lseek(fd, 0, SEEK_SET);
+
/* Start with the initial condition of 0 huge pages*/
if (write(fd, "0", sizeof(char)) != sizeof(char)) {
ksft_print_msg("Failed to write 0 to /proc/sys/vm/nr_hugepages: %s\n",
--
2.30.2
On Wed, 15 May 2024 15:06:32 +0530 Dev Jain <[email protected]> wrote:
> nr_hugepages is not set to zero because the file offset has not been reset
> after read(). Fix that using lseek().
>
Please fully describe the runtime effects of this bug.
On 5/20/24 05:30, Andrew Morton wrote:
> On Wed, 15 May 2024 15:06:32 +0530 Dev Jain <[email protected]> wrote:
>
>> nr_hugepages is not set to zero because the file offset has not been reset
>> after read(). Fix that using lseek().
>>
> Please fully describe the runtime effects of this bug.
This is not a "bug", but a discrepancy; the following comment
by the author says "Start with the initial condition of 0 huge
pages", I am just ensuring that that is actually done. Although,
I am not sure about the utility of doing this in the first place,
since we are anyways trying to increase hugepages after that.
In the second patch, I have moved away this entire logic of
setting nr_hugepages to zero, to the place before we start
filling up memory; if you feel that this patch is unnecessary,
we may squash it.