[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <d476d75d-74a8-9cad-a60e-4b5ecb149719@redhat.com>
Date: Fri, 21 Apr 2023 19:11:18 +0200
From: David Hildenbrand <david@...hat.com>
To: Stefan Roesch <shr@...kernel.io>
Cc: linux-kernel@...r.kernel.org, linux-mm@...ck.org,
linux-s390@...r.kernel.org, linux-kselftest@...r.kernel.org,
Andrew Morton <akpm@...ux-foundation.org>,
Rik van Riel <riel@...riel.com>,
Johannes Weiner <hannes@...xchg.org>,
Michal Hocko <mhocko@...e.com>,
Christian Borntraeger <borntraeger@...ux.ibm.com>,
Janosch Frank <frankja@...ux.ibm.com>,
Claudio Imbrenda <imbrenda@...ux.ibm.com>,
Heiko Carstens <hca@...ux.ibm.com>,
Vasily Gorbik <gor@...ux.ibm.com>,
Sven Schnelle <svens@...ux.ibm.com>,
Shuah Khan <shuah@...nel.org>
Subject: Re: [PATCH v1 1/3] mm/ksm: unmerge and clear VM_MERGEABLE when
setting PR_SET_MEMORY_MERGE=0
[...]
>>
> nit:
> can we do:
>
> if (arg2)
> error = ksm_enable_merge_any(me->mm);
> else
> error = ksm_disable_merge_any(me->mm);
> mmap_write_unlock(me->mm);
> break;
Indeed, thanks.
>
>> diff --git a/mm/ksm.c b/mm/ksm.c
>> index a959e8925413..813f7fbc1832 100644
>> --- a/mm/ksm.c
>> +++ b/mm/ksm.c
>> @@ -2520,6 +2520,22 @@ static void __ksm_add_vma(struct vm_area_struct *vma)
>> vm_flags_set(vma, VM_MERGEABLE);
>> }
>>
>> +static int __ksm_del_vma(struct vm_area_struct *vma)
>> +{
>> + int err;
>> +
>> + if (!(vma->vm_flags & VM_MERGEABLE))
>> + return 0;
>> +
>> + if (vma->anon_vma) {
>> + err = unmerge_ksm_pages(vma, vma->vm_start, vma->vm_end);
>> + if (err)
>> + return err;
>> + }
>> +
>> + vm_flags_clear(vma, VM_MERGEABLE);
>> + return 0;
>> +}
>> /**
>> * ksm_add_vma - Mark vma as mergeable if compatible
>> *
>> @@ -2542,6 +2558,20 @@ static void ksm_add_vmas(struct mm_struct *mm)
>> __ksm_add_vma(vma);
>> }
>>
>> +static int ksm_del_vmas(struct mm_struct *mm)
>> +{
>> + struct vm_area_struct *vma;
>> + int err;
>> +
>> + VMA_ITERATOR(vmi, mm, 0);
>> + for_each_vma(vmi, vma) {
>> + err = __ksm_del_vma(vma);
>> + if (err)
>> + return err;
>> + }
>> + return 0;
>> +}
>> +
>> /**
>> * ksm_enable_merge_any - Add mm to mm ksm list and enable merging on all
>> * compatible VMA's
>> @@ -2569,6 +2599,23 @@ int ksm_enable_merge_any(struct mm_struct *mm)
>> return 0;
>> }
>>
>> +int ksm_disable_merge_any(struct mm_struct *mm)
>>
>
> I understand we want to keep the name "symmetric" with
> ksm_enable_merge_any, but it also unmerges the ksm pages. Do we want to
> reflect that in the function name?
ksm_disable_merge_any_umerge() is suboptimal.
As ksm_disable_merge_any() now reverts what ksm_enable_merge_any() ended
up doing, I think it's just fine.
(it would be a different story if we'd be using "set" / "clear"
terminology instead of "enable" / "disable").
We can describe that in the comment.
>
> Can we add a comment for the function?
Can do for symmetry with ksm_enable_merge_any().
But note that I don't think documentation for functions is of any help
when it takes longer to read the documentation than to read+understand
the actual code.
>
>> +{
>> + int err;
>> +
>> + if (!test_bit(MMF_VM_MERGE_ANY, &mm->flags))
>> + return 0;
>> +
>> + err = ksm_del_vmas(mm);
>> + if (err) {
>> + ksm_add_vmas(mm);
>> + return err;
>> + }
>> +
>> + clear_bit(MMF_VM_MERGE_ANY, &mm->flags);
>>
>
> We only clear the MMF_VM_MERGE_ANY flag if there are no errors. Is this
I think this is the behavior we want. We tried to disable KSM for the
process (previously enabled via the prctl), but cannot disable KSM. So
we rollback our changes and return an error.
This is similar to trying to set MADV_UNMERGEABLE but failing. We leave
the bit set.
> what we want? This means that if the process creates new memory regions
> they would still be marked as mergeable.
Yes, we failed the operation so we keep everything unchanged.
--
Thanks,
David / dhildenb
Powered by blists - more mailing lists