The testcase 'thp04' of LTP will enable THP, do some testing, then
disable it if it wasn't enabled. But this will leave a different value
of min_free_kbytes if it has been set by admin. So I think it's better
to restore the user defined value after disabling THP.
---
thp increases the value of min_free_kbytes in initialization. This will
change the user defined value of min_free_kbytes. So try to restore the
value when disabling thp.
Signed-off-by: Han Pingtian <[email protected]>
---
mm/huge_memory.c | 9 +++++++++
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index 94a824f..276180b 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -164,6 +164,15 @@ static int start_khugepaged(void)
} else if (khugepaged_thread) {
kthread_stop(khugepaged_thread);
khugepaged_thread = NULL;
+
+ if (user_min_free_kbytes >= 0) {
+ pr_info("restore min_free_kbytes from %d to user "
+ "defined %d when stopping khugepaged\n",
+ min_free_kbytes, user_min_free_kbytes);
+
+ min_free_kbytes = user_min_free_kbytes;
+ setup_per_zone_wmarks();
+ }
}
return err;
--
1.7.7.6
On Tue, Jan 21, 2014 at 05:38:59PM +0800, Han Pingtian wrote:
> The testcase 'thp04' of LTP will enable THP, do some testing, then
> disable it if it wasn't enabled. But this will leave a different value
> of min_free_kbytes if it has been set by admin. So I think it's better
> to restore the user defined value after disabling THP.
>
Then have LTP record what min_free_kbytes was at the same time THP was
enabled by the test and restore both settings. It leaves a window where
an admin can set an alternative value during the test but that would also
invalidate the test in same cases and gets filed under "don't do that".
--
Mel Gorman
SUSE Labs
On Tue, Jan 21, 2014 at 10:23:51AM +0000, Mel Gorman wrote:
> On Tue, Jan 21, 2014 at 05:38:59PM +0800, Han Pingtian wrote:
> > The testcase 'thp04' of LTP will enable THP, do some testing, then
> > disable it if it wasn't enabled. But this will leave a different value
> > of min_free_kbytes if it has been set by admin. So I think it's better
> > to restore the user defined value after disabling THP.
> >
>
> Then have LTP record what min_free_kbytes was at the same time THP was
> enabled by the test and restore both settings. It leaves a window where
> an admin can set an alternative value during the test but that would also
> invalidate the test in same cases and gets filed under "don't do that".
>
Because the value is changed in kernel, so it would be better to
restore it in kernel, right? :) I have a v2 patch which will restore
the value only if it isn't set again by user after THP's initialization.
This v2 patch is dependent on the patch 'mm: show message when updating
min_free_kbytes in thp' which has been added to -mm tree, can be found
here:
http://ozlabs.org/~akpm/mmotm/broken-out/mm-show-message-when-updating-min_free_kbytes-in-thp.patch
please have a look. Thanks.
>From 8b79586ff9a1d85cbe45102a86888268094ec0ae Mon Sep 17 00:00:00 2001
From: Han Pingtian <[email protected]>
Date: Tue, 21 Jan 2014 17:24:43 +0800
Subject: [PATCH] mm: restore user defined min_free_kbytes when disabling thp
thp increases the value of min_free_kbytes in initialization. This will
change the user defined value of min_free_kbytes sometimes. So try to
restore the value when disabling thp if the value has been changed in
thp initialization and isn't changed by user afte that.
Signed-off-by: Han Pingtian <[email protected]>
---
mm/huge_memory.c | 10 ++++++++++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index 94a824f..fcb8ce58 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -164,6 +164,16 @@ static int start_khugepaged(void)
} else if (khugepaged_thread) {
kthread_stop(khugepaged_thread);
khugepaged_thread = NULL;
+
+ if (user_min_free_kbytes >= 0 &&
+ user_min_free_kbytes != min_free_kbytes) {
+ pr_info("restore min_free_kbytes from %d to user "
+ "defined %d when stopping khugepaged\n",
+ min_free_kbytes, user_min_free_kbytes);
+
+ min_free_kbytes = user_min_free_kbytes;
+ setup_per_zone_wmarks();
+ }
}
return err;
--
1.7.7.6
On Wed, Jan 22, 2014 at 02:05:06PM +0800, Han Pingtian wrote:
> On Tue, Jan 21, 2014 at 10:23:51AM +0000, Mel Gorman wrote:
> > On Tue, Jan 21, 2014 at 05:38:59PM +0800, Han Pingtian wrote:
> > > The testcase 'thp04' of LTP will enable THP, do some testing, then
> > > disable it if it wasn't enabled. But this will leave a different value
> > > of min_free_kbytes if it has been set by admin. So I think it's better
> > > to restore the user defined value after disabling THP.
> > >
> >
> > Then have LTP record what min_free_kbytes was at the same time THP was
> > enabled by the test and restore both settings. It leaves a window where
> > an admin can set an alternative value during the test but that would also
> > invalidate the test in same cases and gets filed under "don't do that".
> >
>
> Because the value is changed in kernel, so it would be better to
> restore it in kernel, right? :) I have a v2 patch which will restore
> the value only if it isn't set again by user after THP's initialization.
> This v2 patch is dependent on the patch 'mm: show message when updating
> min_free_kbytes in thp' which has been added to -mm tree, can be found
> here:
>
It still feels like the type of scenario that only shows up during tests
that modify kernel parameters as part of the test. I do not consider it
normal operation for THP to be enabled and disabled multiple types during
the lifetime of the system. If the system started with THP disabled, ran
for a long period of time then the benefit of having min_free_kbytes at
a higher value is already lost due to the system being potentially in a
fragmented state already.
I'm ok with the warning being displayed if min_free_kbytes is updated
but I'm not convinced that further trickery is necessary.
--
Mel Gorman
SUSE Labs