From: Michal Hocko <mhocko@suse.com> To: David Hildenbrand <david@redhat.com> Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>, Arnd Bergmann <arnd@arndb.de>, Oscar Salvador <osalvador@suse.de>, Matthew Wilcox <willy@infradead.org>, Andrea Arcangeli <aarcange@redhat.com>, Minchan Kim <minchan@kernel.org>, Jann Horn <jannh@google.com>, Jason Gunthorpe <jgg@ziepe.ca>, Dave Hansen <dave.hansen@intel.com>, Hugh Dickins <hughd@google.com>, Rik van Riel <riel@surriel.com>, "Michael S . Tsirkin" <mst@redhat.com>, "Kirill A . Shutemov" <kirill.shutemov@linux.intel.com>, Vlastimil Babka <vbabka@suse.cz>, Richard Henderson <rth@twiddle.net>, Ivan Kokshaysky <ink@jurassic.park.msu.ru>, Matt Turner <mattst88@gmail.com>, Thomas Bogendoerfer <tsbogend@alpha.franken.de>, "James E.J. Bottomley" <James.Bottomley@hansenpartnership.com>, Helge Deller <deller@gmx.de>, Chris Zankel <chris@zankel.net>, Max Filippov <jcmvbkbc@gmail.com>, linux-alpha@vger.kernel.org, linux-mips@vger.kernel.org, linux-parisc@vger.kernel.org, linux-xtensa@linux-xtensa.org, linux-arch@vger.kernel.org Subject: Re: [PATCH RFC] mm/madvise: introduce MADV_POPULATE to prefault/prealloc memory Date: Mon, 22 Feb 2021 14:19:02 +0100 [thread overview] Message-ID: <YDOvRv8sCVcgF6yC@dhcp22.suse.cz> (raw) In-Reply-To: <73f73cf2-1b4e-bfa9-9a4c-3192d7b7a5ec@redhat.com> On Mon 22-02-21 13:59:55, David Hildenbrand wrote: > On 22.02.21 13:56, Michal Hocko wrote: > > On Sat 20-02-21 10:12:26, David Hildenbrand wrote: > > [...] > > > Thinking about MADV_POPULATE vs. MADV_POPULATE_WRITE I wonder if it would be > > > more versatile to break with existing MAP_POPULATE semantics and directly go > > > with > > > > > > MADV_POPULATE_READ: simulate user space read access without actually > > > reading. Trigger a read fault if required. > > > > > > MADV_POPULATE_WRITE: simulate user space write access without actually > > > writing. Trigger a write fault if required. > > > > > > For my use case, I could use MADV_POPULATE_WRITE on anonymous memory and > > > RAM-backed files (shmem/hugetlb) - I would not have a minor fault when the > > > guest inside the VM first initializes memory. This mimics how QEMU currently > > > preallocates memory. > > > > > > However, I would use MADV_POPULATE_READ on any !RAM-backed files where we > > > actually have to write-back to a (slow?) device. Dirtying everything > > > although the guest might not actually consume it in the near future might be > > > undesired. > > > > Isn't what the current mm_populate does? > > if ((vma->vm_flags & (VM_WRITE | VM_SHARED)) == VM_WRITE) > > gup_flags |= FOLL_WRITE; > > > > So it will write fault to shared memory mappings but it will touch > > others. Ble, I have writen that opposit to the actual behavior. It will write fault on writeable private mappings and only touch on read/only or private mappings. > > Exactly. But for hugetlbfs/shmem ("!RAM-backed files") this is not what we > want. OK, then I must have misread your requirements. Maybe I just got lost in all the combinations you have listed. -- Michal Hocko SUSE Labs
WARNING: multiple messages have this Message-ID (diff)
From: Michal Hocko <mhocko@suse.com> To: David Hildenbrand <david@redhat.com> Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>, Arnd Bergmann <arnd@arndb.de>, Oscar Salvador <osalvador@suse.de>, Matthew Wilcox <willy@infradead.org>, Andrea Arcangeli <aarcange@redhat.com>, Minchan Kim <minchan@kernel.org>, Jann Horn <jannh@google.com>, Jason Gunthorpe <jgg@ziepe.ca>, Dave Hansen <dave.hansen@intel.com>, Hugh Dickins <hughd@google.com>, Rik van Riel <riel@surriel.com>, "Michael S . Tsirkin" <mst@redhat.com>, "Kirill A . Shutemov" <kirill.shutemov@linux.intel.com>, Vlastimil Babka <vbabka@suse.cz>, Richard Henderson <rth@twiddle.net>, Ivan Kokshaysky <ink@jurassic.park.msu.ru>, Matt Turner <mattst88@gmail.com>, Thomas Bogendoerfer <tsbogend@alpha.franken.de>, James E.J. Bottomle Subject: Re: [PATCH RFC] mm/madvise: introduce MADV_POPULATE to prefault/prealloc memory Date: Mon, 22 Feb 2021 14:19:02 +0100 [thread overview] Message-ID: <YDOvRv8sCVcgF6yC@dhcp22.suse.cz> (raw) In-Reply-To: <73f73cf2-1b4e-bfa9-9a4c-3192d7b7a5ec@redhat.com> On Mon 22-02-21 13:59:55, David Hildenbrand wrote: > On 22.02.21 13:56, Michal Hocko wrote: > > On Sat 20-02-21 10:12:26, David Hildenbrand wrote: > > [...] > > > Thinking about MADV_POPULATE vs. MADV_POPULATE_WRITE I wonder if it would be > > > more versatile to break with existing MAP_POPULATE semantics and directly go > > > with > > > > > > MADV_POPULATE_READ: simulate user space read access without actually > > > reading. Trigger a read fault if required. > > > > > > MADV_POPULATE_WRITE: simulate user space write access without actually > > > writing. Trigger a write fault if required. > > > > > > For my use case, I could use MADV_POPULATE_WRITE on anonymous memory and > > > RAM-backed files (shmem/hugetlb) - I would not have a minor fault when the > > > guest inside the VM first initializes memory. This mimics how QEMU currently > > > preallocates memory. > > > > > > However, I would use MADV_POPULATE_READ on any !RAM-backed files where we > > > actually have to write-back to a (slow?) device. Dirtying everything > > > although the guest might not actually consume it in the near future might be > > > undesired. > > > > Isn't what the current mm_populate does? > > if ((vma->vm_flags & (VM_WRITE | VM_SHARED)) == VM_WRITE) > > gup_flags |= FOLL_WRITE; > > > > So it will write fault to shared memory mappings but it will touch > > others. Ble, I have writen that opposit to the actual behavior. It will write fault on writeable private mappings and only touch on read/only or private mappings. > > Exactly. But for hugetlbfs/shmem ("!RAM-backed files") this is not what we > want. OK, then I must have misread your requirements. Maybe I just got lost in all the combinations you have listed. -- Michal Hocko SUSE Labs
next prev parent reply other threads:[~2021-02-22 13:22 UTC|newest] Thread overview: 76+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-02-17 15:48 [PATCH RFC] mm/madvise: introduce MADV_POPULATE to prefault/prealloc memory David Hildenbrand 2021-02-17 15:48 ` David Hildenbrand 2021-02-17 16:46 ` Dave Hansen 2021-02-17 16:46 ` Dave Hansen 2021-02-17 17:06 ` David Hildenbrand 2021-02-17 17:06 ` David Hildenbrand 2021-02-17 17:21 ` Vlastimil Babka 2021-02-17 17:21 ` Vlastimil Babka 2021-02-18 11:07 ` Rolf Eike Beer 2021-02-18 11:07 ` Rolf Eike Beer 2021-02-18 11:27 ` David Hildenbrand 2021-02-18 11:27 ` David Hildenbrand 2021-02-18 10:25 ` Michal Hocko 2021-02-18 10:25 ` Michal Hocko 2021-02-18 10:44 ` David Hildenbrand 2021-02-18 10:44 ` David Hildenbrand 2021-02-18 10:54 ` David Hildenbrand 2021-02-18 10:54 ` David Hildenbrand 2021-02-18 11:28 ` Michal Hocko 2021-02-18 11:28 ` Michal Hocko 2021-02-18 11:27 ` Michal Hocko 2021-02-18 11:27 ` Michal Hocko 2021-02-18 11:38 ` David Hildenbrand 2021-02-18 11:38 ` David Hildenbrand 2021-02-18 12:22 ` [PATCH RFC] madvise.2: Document MADV_POPULATE David Hildenbrand 2021-02-18 12:22 ` David Hildenbrand 2021-02-18 22:59 ` [PATCH RFC] mm/madvise: introduce MADV_POPULATE to prefault/prealloc memory Peter Xu 2021-02-18 22:59 ` Peter Xu 2021-02-19 8:20 ` David Hildenbrand 2021-02-19 8:20 ` David Hildenbrand 2021-02-19 16:31 ` Peter Xu 2021-02-19 16:31 ` Peter Xu 2021-02-19 17:13 ` David Hildenbrand 2021-02-19 17:13 ` David Hildenbrand 2021-02-19 19:14 ` David Hildenbrand 2021-02-19 19:14 ` David Hildenbrand 2021-02-19 19:25 ` Mike Kravetz 2021-02-19 19:25 ` Mike Kravetz 2021-02-20 9:01 ` David Hildenbrand 2021-02-20 9:01 ` David Hildenbrand 2021-02-19 19:23 ` Peter Xu 2021-02-19 19:23 ` Peter Xu 2021-02-19 20:04 ` David Hildenbrand 2021-02-19 20:04 ` David Hildenbrand 2021-02-22 12:46 ` Michal Hocko 2021-02-22 12:46 ` Michal Hocko 2021-02-22 12:52 ` David Hildenbrand 2021-02-22 12:52 ` David Hildenbrand 2021-02-19 10:35 ` Michal Hocko 2021-02-19 10:35 ` Michal Hocko 2021-02-19 10:43 ` David Hildenbrand 2021-02-19 10:43 ` David Hildenbrand 2021-02-19 11:04 ` Michal Hocko 2021-02-19 11:04 ` Michal Hocko 2021-02-19 11:10 ` David Hildenbrand 2021-02-19 11:10 ` David Hildenbrand 2021-02-20 9:12 ` David Hildenbrand 2021-02-20 9:12 ` David Hildenbrand 2021-02-22 12:56 ` Michal Hocko 2021-02-22 12:56 ` Michal Hocko 2021-02-22 12:59 ` David Hildenbrand 2021-02-22 12:59 ` David Hildenbrand 2021-02-22 13:19 ` Michal Hocko [this message] 2021-02-22 13:19 ` Michal Hocko 2021-02-22 13:22 ` David Hildenbrand 2021-02-22 13:22 ` David Hildenbrand 2021-02-22 14:02 ` Michal Hocko 2021-02-22 14:02 ` Michal Hocko 2021-02-22 15:30 ` David Hildenbrand 2021-02-22 15:30 ` David Hildenbrand 2021-02-24 14:25 ` David Hildenbrand 2021-02-24 14:25 ` David Hildenbrand 2021-02-24 14:38 ` David Hildenbrand 2021-02-24 14:38 ` David Hildenbrand 2021-02-25 8:41 ` David Hildenbrand 2021-02-25 8:41 ` David Hildenbrand
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=YDOvRv8sCVcgF6yC@dhcp22.suse.cz \ --to=mhocko@suse.com \ --cc=James.Bottomley@hansenpartnership.com \ --cc=aarcange@redhat.com \ --cc=akpm@linux-foundation.org \ --cc=arnd@arndb.de \ --cc=chris@zankel.net \ --cc=dave.hansen@intel.com \ --cc=david@redhat.com \ --cc=deller@gmx.de \ --cc=hughd@google.com \ --cc=ink@jurassic.park.msu.ru \ --cc=jannh@google.com \ --cc=jcmvbkbc@gmail.com \ --cc=jgg@ziepe.ca \ --cc=kirill.shutemov@linux.intel.com \ --cc=linux-alpha@vger.kernel.org \ --cc=linux-arch@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mips@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=linux-parisc@vger.kernel.org \ --cc=linux-xtensa@linux-xtensa.org \ --cc=mattst88@gmail.com \ --cc=minchan@kernel.org \ --cc=mst@redhat.com \ --cc=osalvador@suse.de \ --cc=riel@surriel.com \ --cc=rth@twiddle.net \ --cc=tsbogend@alpha.franken.de \ --cc=vbabka@suse.cz \ --cc=willy@infradead.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.