From: Blaisorblade <blaisorblade@yahoo.it> To: Nick Piggin <npiggin@suse.de> Cc: Bill Irwin <bill.irwin@oracle.com>, Ingo Molnar <mingo@elte.hu>, Andrew Morton <akpm@linux-foundation.org>, Linux Memory Management <linux-mm@kvack.org>, Linux Kernel <linux-kernel@vger.kernel.org>, Benjamin Herrenschmidt <benh@kernel.crashing.org> Subject: Re: [patch 4/6] mm: merge populate and nopage into fault (fixes nonlinear) Date: Tue, 13 Mar 2007 00:01:13 +0100 [thread overview] Message-ID: <200703130001.13467.blaisorblade@yahoo.it> (raw) In-Reply-To: <20070307100242.GG8609@wotan.suse.de> On Wednesday 07 March 2007 11:02, Nick Piggin wrote: > On Wed, Mar 07, 2007 at 10:49:47AM +0100, Nick Piggin wrote: > > On Wed, Mar 07, 2007 at 01:44:20AM -0800, Bill Irwin wrote: > > > On Wed, Mar 07, 2007 at 10:28:21AM +0100, Nick Piggin wrote: > > > > Depending on whether anyone wants it, and what features they want, we > > > > could emulate the old syscall, and make a new restricted one which is > > > > much less intrusive. > > > > For example, if we can operate only on MAP_ANONYMOUS memory and > > > > specify that nonlinear mappings effectively mlock the pages, then we > > > > can get rid of all the objrmap and unmap_mapping_range handling, > > > > forget about the writeout and msync problems... > > > > > > Anonymous-only would make it a doorstop for Oracle, since its entire > > > motive for using it is to window into objects larger than user virtual > > > > Uh, duh yes I don't mean MAP_ANONYMOUS, I was just thinking of the shmem > > inode that sits behind MAP_ANONYMOUS|MAP_SHARED. Of course if you don't > > have a file descriptor to get a pgoff, then remap_file_pages is a > > doorstop for everyone ;) > > > > > address spaces (this likely also applies to UML, though they should > > > really chime in to confirm). Restrictions to tmpfs and/or ramfs would > > > likely be liveable, though I suspect some things might want to do it to > > > shm segments (I'll ask about that one). There's definitely no need for > > > a persistent backing store for the object to be remapped in Oracle's > > > case, in any event. It's largely the in-core destination and source of > > > IO, not something saved on-disk itself. > > > > Yeah, tmpfs/shm segs are what I was thinking about. If UML can live with > > that as well, then I think it might be a good option. > > Oh, hmm.... if you can truncate these things then you still need to > force unmap so you still need i_mmap_nonlinear. Well, we don't need truncate(), but MADV_REMOVE for memory hotunplug, which is way similar I guess. About the restriction to tmpfs, I have just discovered '[PATCH] mm: tracking shared dirty pages' (commit d08b3851da41d0ee60851f2c75b118e1f7a5fc89), which already partially conflicts with remap_file_pages for file-based mmaps (and that's fully fine, for now). Even if UML does not need it, till now if there is a VMA protection and a page hasn't been remapped with remap_file_pages, the VMA protection is used (just because it makes sense). However, it is only used when the PTE is first created - we can never change protections on a VMA - so it vma_wants_writenotify() is true (on all file-based and on no shmfs based mapping, right?), and we write-protect the VMA, it will always be write-protected. That's no problem for UML, but for any other user (I guess I'll have to prevent callers from trying such stuff - I started from a pretty generic patch). > But come to think of it, I still don't think nonlinear mappings are > too bad as they are ;) Btw, I really like removing ->populate and merging the common code together. filemap_populate and shmem_populate are so obnoxiously different that I already wanted to do that (after merging remap_file_pages() core). Also, I'm curious. Since my patches are already changing remap_file_pages() code, should they be absolutely merged after yours? -- Inform me of my mistakes, so I can add them to my list! Paolo Giarrusso, aka Blaisorblade http://www.user-mode-linux.org/~blaisorblade Chiacchiera con i tuoi amici in tempo reale! http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com
WARNING: multiple messages have this Message-ID (diff)
From: Blaisorblade <blaisorblade@yahoo.it> To: Nick Piggin <npiggin@suse.de> Cc: Bill Irwin <bill.irwin@oracle.com>, Ingo Molnar <mingo@elte.hu>, Andrew Morton <akpm@linux-foundation.org>, Linux Memory Management <linux-mm@kvack.org>, Linux Kernel <linux-kernel@vger.kernel.org>, Benjamin Herrenschmidt <benh@kernel.crashing.org> Subject: Re: [patch 4/6] mm: merge populate and nopage into fault (fixes nonlinear) Date: Tue, 13 Mar 2007 00:01:13 +0100 [thread overview] Message-ID: <200703130001.13467.blaisorblade@yahoo.it> (raw) In-Reply-To: <20070307100242.GG8609@wotan.suse.de> On Wednesday 07 March 2007 11:02, Nick Piggin wrote: > On Wed, Mar 07, 2007 at 10:49:47AM +0100, Nick Piggin wrote: > > On Wed, Mar 07, 2007 at 01:44:20AM -0800, Bill Irwin wrote: > > > On Wed, Mar 07, 2007 at 10:28:21AM +0100, Nick Piggin wrote: > > > > Depending on whether anyone wants it, and what features they want, we > > > > could emulate the old syscall, and make a new restricted one which is > > > > much less intrusive. > > > > For example, if we can operate only on MAP_ANONYMOUS memory and > > > > specify that nonlinear mappings effectively mlock the pages, then we > > > > can get rid of all the objrmap and unmap_mapping_range handling, > > > > forget about the writeout and msync problems... > > > > > > Anonymous-only would make it a doorstop for Oracle, since its entire > > > motive for using it is to window into objects larger than user virtual > > > > Uh, duh yes I don't mean MAP_ANONYMOUS, I was just thinking of the shmem > > inode that sits behind MAP_ANONYMOUS|MAP_SHARED. Of course if you don't > > have a file descriptor to get a pgoff, then remap_file_pages is a > > doorstop for everyone ;) > > > > > address spaces (this likely also applies to UML, though they should > > > really chime in to confirm). Restrictions to tmpfs and/or ramfs would > > > likely be liveable, though I suspect some things might want to do it to > > > shm segments (I'll ask about that one). There's definitely no need for > > > a persistent backing store for the object to be remapped in Oracle's > > > case, in any event. It's largely the in-core destination and source of > > > IO, not something saved on-disk itself. > > > > Yeah, tmpfs/shm segs are what I was thinking about. If UML can live with > > that as well, then I think it might be a good option. > > Oh, hmm.... if you can truncate these things then you still need to > force unmap so you still need i_mmap_nonlinear. Well, we don't need truncate(), but MADV_REMOVE for memory hotunplug, which is way similar I guess. About the restriction to tmpfs, I have just discovered '[PATCH] mm: tracking shared dirty pages' (commit d08b3851da41d0ee60851f2c75b118e1f7a5fc89), which already partially conflicts with remap_file_pages for file-based mmaps (and that's fully fine, for now). Even if UML does not need it, till now if there is a VMA protection and a page hasn't been remapped with remap_file_pages, the VMA protection is used (just because it makes sense). However, it is only used when the PTE is first created - we can never change protections on a VMA - so it vma_wants_writenotify() is true (on all file-based and on no shmfs based mapping, right?), and we write-protect the VMA, it will always be write-protected. That's no problem for UML, but for any other user (I guess I'll have to prevent callers from trying such stuff - I started from a pretty generic patch). > But come to think of it, I still don't think nonlinear mappings are > too bad as they are ;) Btw, I really like removing ->populate and merging the common code together. filemap_populate and shmem_populate are so obnoxiously different that I already wanted to do that (after merging remap_file_pages() core). Also, I'm curious. Since my patches are already changing remap_file_pages() code, should they be absolutely merged after yours? -- Inform me of my mistakes, so I can add them to my list! Paolo Giarrusso, aka Blaisorblade http://www.user-mode-linux.org/~blaisorblade Chiacchiera con i tuoi amici in tempo reale! http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2007-03-12 23:01 UTC|newest] Thread overview: 198+ messages / expand[flat|nested] mbox.gz Atom feed top 2007-02-21 4:49 [patch 0/6] fault vs truncate/invalidate race fix Nick Piggin 2007-02-21 4:49 ` Nick Piggin 2007-02-21 4:49 ` [patch 1/6] mm: debug check for the fault vs invalidate race Nick Piggin 2007-02-21 4:49 ` Nick Piggin 2007-02-21 4:49 ` [patch 2/6] mm: simplify filemap_nopage Nick Piggin 2007-02-21 4:49 ` Nick Piggin 2007-02-21 4:50 ` [patch 3/6] mm: fix fault vs invalidate race for linear mappings Nick Piggin 2007-02-21 4:50 ` Nick Piggin 2007-03-07 6:36 ` Andrew Morton 2007-03-07 6:36 ` Andrew Morton 2007-03-07 6:57 ` Nick Piggin 2007-03-07 6:57 ` Nick Piggin 2007-03-07 7:08 ` Andrew Morton 2007-03-07 7:08 ` Andrew Morton 2007-03-07 7:25 ` Nick Piggin 2007-03-07 7:25 ` Nick Piggin 2007-02-21 4:50 ` [patch 4/6] mm: merge populate and nopage into fault (fixes nonlinear) Nick Piggin 2007-02-21 4:50 ` Nick Piggin 2007-03-07 6:51 ` Andrew Morton 2007-03-07 6:51 ` Andrew Morton 2007-03-07 7:08 ` Nick Piggin 2007-03-07 7:08 ` Nick Piggin 2007-03-07 8:19 ` Nick Piggin 2007-03-07 8:19 ` Nick Piggin 2007-03-07 8:27 ` Ingo Molnar 2007-03-07 8:27 ` Ingo Molnar 2007-03-07 8:35 ` Andrew Morton 2007-03-07 8:35 ` Andrew Morton 2007-03-07 8:53 ` Ingo Molnar 2007-03-07 8:53 ` Ingo Molnar 2007-03-07 9:28 ` Nick Piggin 2007-03-07 9:28 ` Nick Piggin 2007-03-07 9:44 ` Bill Irwin 2007-03-07 9:44 ` Bill Irwin 2007-03-07 9:49 ` Nick Piggin 2007-03-07 9:49 ` Nick Piggin 2007-03-07 10:02 ` Nick Piggin 2007-03-07 10:02 ` Nick Piggin 2007-03-12 23:01 ` Blaisorblade [this message] 2007-03-12 23:01 ` Blaisorblade 2007-03-13 1:19 ` Nick Piggin 2007-03-13 1:19 ` Nick Piggin 2007-03-17 12:17 ` Blaisorblade 2007-03-17 12:17 ` Blaisorblade 2007-03-18 2:50 ` Nick Piggin 2007-03-18 2:50 ` Nick Piggin 2007-03-18 13:09 ` Jeff Dike 2007-03-18 13:09 ` Jeff Dike 2007-03-19 12:04 ` Bill Irwin 2007-03-19 12:04 ` Bill Irwin 2007-03-19 20:44 ` Blaisorblade 2007-03-19 20:44 ` Blaisorblade 2007-03-20 6:00 ` Nick Piggin 2007-03-20 6:00 ` Nick Piggin 2007-03-21 19:45 ` Blaisorblade 2007-03-21 19:45 ` Blaisorblade 2007-03-08 12:39 ` Blaisorblade 2007-03-08 12:39 ` Blaisorblade 2007-03-07 9:29 ` Bill Irwin 2007-03-07 9:29 ` Bill Irwin 2007-03-07 9:39 ` Andrew Morton 2007-03-07 9:39 ` Andrew Morton 2007-03-07 10:09 ` Bill Irwin 2007-03-07 10:09 ` Bill Irwin 2007-03-07 8:38 ` Miklos Szeredi 2007-03-07 8:38 ` Miklos Szeredi 2007-03-07 8:47 ` Andrew Morton 2007-03-07 8:47 ` Andrew Morton 2007-03-07 8:51 ` Miklos Szeredi 2007-03-07 8:51 ` Miklos Szeredi 2007-03-07 9:07 ` Andrew Morton 2007-03-07 9:07 ` Andrew Morton 2007-03-07 9:18 ` Nick Piggin 2007-03-07 9:18 ` Nick Piggin 2007-03-07 9:26 ` Andrew Morton 2007-03-07 9:26 ` Andrew Morton 2007-03-07 9:28 ` Miklos Szeredi 2007-03-07 9:28 ` Miklos Szeredi 2007-03-07 9:38 ` Nick Piggin 2007-03-07 9:38 ` Nick Piggin 2007-03-07 9:25 ` Miklos Szeredi 2007-03-07 9:25 ` Miklos Szeredi 2007-03-07 9:32 ` Peter Zijlstra 2007-03-07 9:32 ` Peter Zijlstra 2007-03-07 9:45 ` Nick Piggin 2007-03-07 9:45 ` Nick Piggin 2007-03-07 10:04 ` Nick Piggin 2007-03-07 10:04 ` Nick Piggin 2007-03-07 10:06 ` Peter Zijlstra 2007-03-07 10:06 ` Peter Zijlstra 2007-03-07 10:13 ` Miklos Szeredi 2007-03-07 10:13 ` Miklos Szeredi 2007-03-07 10:21 ` Nick Piggin 2007-03-07 10:21 ` Nick Piggin 2007-03-07 10:24 ` Peter Zijlstra 2007-03-07 10:24 ` Peter Zijlstra 2007-03-07 10:38 ` Nick Piggin 2007-03-07 10:38 ` Nick Piggin 2007-03-07 10:47 ` Peter Zijlstra 2007-03-07 10:47 ` Peter Zijlstra 2007-03-07 11:00 ` Nick Piggin 2007-03-07 11:00 ` Nick Piggin 2007-03-07 11:48 ` Peter Zijlstra 2007-03-07 11:48 ` Peter Zijlstra 2007-03-07 12:17 ` Nick Piggin 2007-03-07 12:17 ` Nick Piggin 2007-03-07 12:41 ` Peter Zijlstra 2007-03-07 12:41 ` Peter Zijlstra 2007-03-07 13:08 ` Nick Piggin 2007-03-07 13:08 ` Nick Piggin 2007-03-07 13:19 ` Peter Zijlstra 2007-03-07 13:19 ` Peter Zijlstra 2007-03-07 13:36 ` Nick Piggin 2007-03-07 13:36 ` Nick Piggin 2007-03-07 13:52 ` Peter Zijlstra 2007-03-07 13:52 ` Peter Zijlstra 2007-03-07 13:56 ` Miklos Szeredi 2007-03-07 13:56 ` Miklos Szeredi 2007-03-07 14:34 ` Peter Zijlstra 2007-03-07 14:34 ` Peter Zijlstra 2007-03-07 15:01 ` Nick Piggin 2007-03-07 15:01 ` Nick Piggin 2007-03-07 16:58 ` [RFC][PATCH] mm: fix page_mkclean() vs non-linear vmas Peter Zijlstra 2007-03-07 16:58 ` Peter Zijlstra 2007-03-07 18:00 ` Linus Torvalds 2007-03-07 18:00 ` Linus Torvalds 2007-03-07 18:12 ` Peter Zijlstra 2007-03-07 18:12 ` Peter Zijlstra 2007-03-07 18:24 ` Peter Zijlstra 2007-03-07 18:24 ` Peter Zijlstra 2007-03-08 11:21 ` Miklos Szeredi 2007-03-08 11:21 ` Miklos Szeredi 2007-03-08 11:37 ` Peter Zijlstra 2007-03-08 11:37 ` Peter Zijlstra 2007-03-08 11:48 ` Miklos Szeredi 2007-03-08 11:48 ` Miklos Szeredi 2007-03-08 12:11 ` Peter Zijlstra 2007-03-08 12:11 ` Peter Zijlstra 2007-03-08 12:19 ` Nick Piggin 2007-03-08 12:19 ` Nick Piggin 2007-03-08 12:25 ` Miklos Szeredi 2007-03-08 12:25 ` Miklos Szeredi 2007-03-08 11:58 ` Nick Piggin 2007-03-08 11:58 ` Nick Piggin 2007-03-08 12:09 ` Miklos Szeredi 2007-03-08 12:09 ` Miklos Szeredi 2007-03-07 15:10 ` [patch 4/6] mm: merge populate and nopage into fault (fixes nonlinear) Jeff Dike 2007-03-07 15:10 ` Jeff Dike 2007-03-07 13:53 ` Miklos Szeredi 2007-03-07 13:53 ` Miklos Szeredi 2007-03-07 14:50 ` Nick Piggin 2007-03-07 14:50 ` Nick Piggin 2007-03-07 12:22 ` Bill Irwin 2007-03-07 12:22 ` Bill Irwin 2007-03-07 12:36 ` Nick Piggin 2007-03-07 12:36 ` Nick Piggin 2007-03-07 10:30 ` [rfc][patch 7/6] mm: merge page_mkwrite Nick Piggin 2007-03-07 10:30 ` Nick Piggin 2007-03-07 8:59 ` [patch 4/6] mm: merge populate and nopage into fault (fixes nonlinear) Nick Piggin 2007-03-07 8:59 ` Nick Piggin 2007-03-07 9:11 ` Nick Piggin 2007-03-07 9:11 ` Nick Piggin 2007-03-07 9:22 ` Ingo Molnar 2007-03-07 9:22 ` Ingo Molnar 2007-03-07 9:32 ` Bill Irwin 2007-03-07 9:32 ` Bill Irwin 2007-03-07 9:35 ` Ingo Molnar 2007-03-07 9:35 ` Ingo Molnar 2007-03-07 9:50 ` Bill Irwin 2007-03-07 9:50 ` Bill Irwin 2007-03-07 9:52 ` Nick Piggin 2007-03-07 9:52 ` Nick Piggin 2007-03-07 7:19 ` Bill Irwin 2007-03-07 7:19 ` Bill Irwin 2007-03-07 10:05 ` Benjamin Herrenschmidt 2007-03-07 10:05 ` Benjamin Herrenschmidt 2007-03-07 10:17 ` Nick Piggin 2007-03-07 10:17 ` Nick Piggin 2007-03-07 10:46 ` Benjamin Herrenschmidt 2007-03-07 10:46 ` Benjamin Herrenschmidt 2007-02-21 4:50 ` [patch 5/6] mm: merge nopfn into fault Nick Piggin 2007-02-21 4:50 ` Nick Piggin 2007-02-21 5:13 ` Nick Piggin 2007-02-21 5:13 ` Nick Piggin 2007-02-21 4:50 ` [patch 6/6] mm: remove legacy cruft Nick Piggin 2007-02-21 4:50 ` Nick Piggin 2007-02-27 4:36 ` [patch 0/6] fault vs truncate/invalidate race fix Dave Airlie 2007-02-27 4:36 ` Dave Airlie 2007-02-27 5:32 ` Andrew Morton 2007-02-27 5:32 ` Andrew Morton 2007-02-27 6:26 ` Dave Airlie 2007-02-27 6:26 ` Dave Airlie 2007-02-27 6:54 ` Benjamin Herrenschmidt 2007-02-27 6:54 ` Benjamin Herrenschmidt 2007-03-18 23:13 ` Dave Airlie 2007-03-18 23:13 ` Dave Airlie 2007-02-27 8:50 ` Nick Piggin 2007-02-27 8:50 ` Nick Piggin
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=200703130001.13467.blaisorblade@yahoo.it \ --to=blaisorblade@yahoo.it \ --cc=akpm@linux-foundation.org \ --cc=benh@kernel.crashing.org \ --cc=bill.irwin@oracle.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=mingo@elte.hu \ --cc=npiggin@suse.de \ /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.