[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1ba2aafb-468d-4f99-9a89-672581ff7e4c@suse.cz>
Date: Fri, 25 Oct 2024 12:23:46 +0200
From: Vlastimil Babka <vbabka@...e.cz>
To: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
"Liam R . Howlett" <Liam.Howlett@...cle.com>, Jann Horn <jannh@...gle.com>,
linux-kernel@...r.kernel.org, linux-mm@...ck.org,
Linus Torvalds <torvalds@...ux-foundation.org>, Peter Xu <peterx@...hat.com>
Subject: Re: [PATCH v2 7/8] mm: refactor __mmap_region()
On 10/25/24 12:19, Lorenzo Stoakes wrote:
> On Fri, Oct 25, 2024 at 10:35:20AM +0200, Vlastimil Babka wrote:
>> >
>> > /* Lock the VMA since it is modified after insertion into VMA tree */
>> > vma_start_write(vma);
>> > - vma_iter_store(&vmi, vma);
>> > - mm->map_count++;
>> > + vma_iter_store(vmi, vma);
>> > + map->mm->map_count++;
>> > vma_link_file(vma);
>> >
>> > /*
>> > * vma_merge_new_range() calls khugepaged_enter_vma() too, the below
>> > * call covers the non-merge case.
>> > */
>> > - khugepaged_enter_vma(vma, vma->vm_flags);
>> > + khugepaged_enter_vma(vma, map->flags);
>> >
>> > file_expanded:
>> > - file = vma->vm_file;
>> > ksm_add_vma(vma);
>>
>> I'm wondering if this could go to the "non file expanded" region above. If
>> we expanded a vma, it was either in ksm and stays in ksm, or it was not
>> eligible and that couldn't have changed by expanding?
>
> We could change this, but the next commit removes the need for this :)
Yeah, no need to change here then.
Powered by blists - more mailing lists