[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6e5a5bde-cedb-9d0a-f8c1-22406085b6b9@redhat.com>
Date: Fri, 19 Feb 2021 11:43:48 +0100
From: David Hildenbrand <david@...hat.com>
To: Michal Hocko <mhocko@...e.com>
Cc: linux-kernel@...r.kernel.org, linux-mm@...ck.org,
Andrew Morton <akpm@...ux-foundation.org>,
Arnd Bergmann <arnd@...db.de>,
Oscar Salvador <osalvador@...e.de>,
Matthew Wilcox <willy@...radead.org>,
Andrea Arcangeli <aarcange@...hat.com>,
Minchan Kim <minchan@...nel.org>, Jann Horn <jannh@...gle.com>,
Jason Gunthorpe <jgg@...pe.ca>,
Dave Hansen <dave.hansen@...el.com>,
Hugh Dickins <hughd@...gle.com>,
Rik van Riel <riel@...riel.com>,
"Michael S . Tsirkin" <mst@...hat.com>,
"Kirill A . Shutemov" <kirill.shutemov@...ux.intel.com>,
Vlastimil Babka <vbabka@...e.cz>,
Richard Henderson <rth@...ddle.net>,
Ivan Kokshaysky <ink@...assic.park.msu.ru>,
Matt Turner <mattst88@...il.com>,
Thomas Bogendoerfer <tsbogend@...ha.franken.de>,
"James E.J. Bottomley" <James.Bottomley@...senpartnership.com>,
Helge Deller <deller@....de>, Chris Zankel <chris@...kel.net>,
Max Filippov <jcmvbkbc@...il.com>, linux-alpha@...r.kernel.org,
linux-mips@...r.kernel.org, linux-parisc@...r.kernel.org,
linux-xtensa@...ux-xtensa.org, linux-arch@...r.kernel.org
Subject: Re: [PATCH RFC] mm/madvise: introduce MADV_POPULATE to
prefault/prealloc memory
On 19.02.21 11:35, Michal Hocko wrote:
> On Wed 17-02-21 16:48:44, David Hildenbrand wrote:
> [...]
>
> I only got to the implementation now.
>
>> +static long madvise_populate(struct vm_area_struct *vma,
>> + struct vm_area_struct **prev,
>> + unsigned long start, unsigned long end)
>> +{
>> + struct mm_struct *mm = vma->vm_mm;
>> + unsigned long tmp_end;
>> + int locked = 1;
>> + long pages;
>> +
>> + *prev = vma;
>> +
>> + while (start < end) {
>> + /*
>> + * We might have temporarily dropped the lock. For example,
>> + * our VMA might have been split.
>> + */
>> + if (!vma || start >= vma->vm_end) {
>> + vma = find_vma(mm, start);
>> + if (!vma)
>> + return -ENOMEM;
>> + }
>
> Why do you need to find a vma when you already have one. do_madvise will
> give you your vma already. I do understand that you want to finish the
> vma for some errors but that shouldn't require handling vmas. You should
> be in the shope of one here unless I miss anything.
See below, we might temporary drop the lock while not having processed
all pages
>
>> +
>> + /* Bail out on incompatible VMA types. */
>> + if (vma->vm_flags & (VM_IO | VM_PFNMAP) ||
>> + !vma_is_accessible(vma)) {
>> + return -EINVAL;
>> + }
>> +
>> + /*
>> + * Populate pages and take care of VM_LOCKED: simulate user
>> + * space access.
>> + *
>> + * For private, writable mappings, trigger a write fault to
>> + * break COW (i.e., shared zeropage). For other mappings (i.e.,
>> + * read-only, shared), trigger a read fault.
>> + */
>> + tmp_end = min_t(unsigned long, end, vma->vm_end);
>> + pages = populate_vma_page_range(vma, start, tmp_end, &locked);
>> + if (!locked) {
>> + mmap_read_lock(mm);
>> + *prev = NULL;
>> + vma = NULL;
^ here
so, the VMA might have been replaced/split/... in the meantime.
So to make forward progress, I have to lookup again. (similar. but
different to madvise_dontneed_free()).
--
Thanks,
David / dhildenb
Powered by blists - more mailing lists