>> Am 26.02.2014 um 01:19 schrieb Peter Zijlstra <peterz@xxxxxxxxxxxxx>:
>>
>>> On Tue, Feb 25, 2014 at 12:15:28PM -0500, Johannes Weiner wrote:
>>> On Tue, Feb 25, 2014 at 12:28:04AM +0100, Alexander Graf wrote:
>>> Configuration of tunables and Linux virtual memory settings has traditionally
>>> happened via sysctl. Thanks to that there are well established ways to make
>>> sysctl configuration bits persistent (sysctl.conf).
>>>
>>> KSM introduced a sysfs based configuration path which is not covered by user
>>> space persistent configuration frameworks.
>>>
>>> In order to make life easy for sysadmins, this patch adds all access to all
>>> KSM tunables via sysctl as well. That way sysctl.conf works for KSM as well,
>>> giving us a streamlined way to make KSM configuration persistent.
>>>
>>> Reported-by: Sasche Peilicke <speilicke@xxxxxxxx>
>>> Signed-off-by: Alexander Graf <agraf@xxxxxxx>
>>> ---
>>> kernel/sysctl.c | 10 +++++++
>>> mm/ksm.c | 78 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>> 2 files changed, 88 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/kernel/sysctl.c b/kernel/sysctl.c
>>> index 332cefc..2169a00 100644
>>> --- a/kernel/sysctl.c
>>> +++ b/kernel/sysctl.c
>>> @@ -217,6 +217,9 @@ extern struct ctl_table random_table[];
>>> #ifdef CONFIG_EPOLL
>>> extern struct ctl_table epoll_table[];
>>> #endif
>>> +#ifdef CONFIG_KSM
>>> +extern struct ctl_table ksm_table[];
>>> +#endif
>>>
>>> #ifdef HAVE_ARCH_PICK_MMAP_LAYOUT
>>> int sysctl_legacy_va_layout;
>>> @@ -1279,6 +1282,13 @@ static struct ctl_table vm_table[] = {
>>> },
>>>
>>> #endif /* CONFIG_COMPACTION */
>>> +#ifdef CONFIG_KSM
>>> + {
>>> + .procname = "ksm",
>>> + .mode = 0555,
>>> + .child = ksm_table,
>>> + },
>>> +#endif
>>
>> ksm can be a module, so this won't work.
>>
>> Can we make those controls proper module parameters instead?
>
> You can do dynamic sysctl registration and removal. Its its own little
> filesystem of sorts.
Hm. Doesn't this open another big can of worms? If we have ksm as a module and our sysctl helpers try to enable ksm on boot, they may not be able to because the module hasn't been loaded yet.
So in that case, we want to always register the sysctl and dynamically load the ksm module when the sysctl gets accessed - similar to how we can do stub devices that load modiles, no?
Alex
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href