From: Nicolas Pitre <nicolas.pitre@linaro.org> To: Christoph Hellwig <hch@infradead.org> Cc: Richard Weinberger <richard.weinberger@gmail.com>, Alexander Viro <viro@zeniv.linux.org.uk>, "linux-mm@kvack.org" <linux-mm@kvack.org>, linux-fsdevel <linux-fsdevel@vger.kernel.org>, "linux-embedded@vger.kernel.org" <linux-embedded@vger.kernel.org>, LKML <linux-kernel@vger.kernel.org>, Chris Brandt <Chris.Brandt@renesas.com> Subject: Re: [PATCH v4 4/5] cramfs: add mmap support Date: Thu, 5 Oct 2017 13:52:03 -0400 (EDT) [thread overview] Message-ID: <nycvar.YSQ.7.76.1710051203260.1693@knanqh.ubzr> (raw) In-Reply-To: <20171005071545.GA23364@infradead.org> On Thu, 5 Oct 2017, Christoph Hellwig wrote: > On Wed, Oct 04, 2017 at 04:47:52PM -0400, Nicolas Pitre wrote: > > The only downside so far is the lack of visibility from user space to > > confirm it actually works as intended. With the vma splitting approach > > you clearly see what gets directly mapped in /proc/*/maps thanks to > > remap_pfn_range() storing the actual physical address in vma->vm_pgoff. > > With VM_MIXEDMAP things are no longer visible. Any opinion for the best > > way to overcome this? > > Add trace points that allow you to trace it using trace-cmd, perf > or just tracefs? In memory constrained embedded environments those facilities are sometimes too big to be practical. And the /proc/*/maps content is static i.e. it is always there regardless of how many tasks you have and how long they've been running which makes it extremely handy. > > Anyway, here's a replacement for patch 4/5 below: > > This looks much better, and is about 100 lines less than the previous > version. More (mostly cosmetic) comments below: > [...] > > + fail_reason = "vma is writable"; > > + if (vma->vm_flags & VM_WRITE) > > + goto fail; > > The fail_reaosn is a rather unusable style, is there any good reason > why you need it here? We generall don't add a debug printk for every > pssible failure case. There are many things that might make your files not XIP and they're mostly related to how the file is mmap'd or how mkcramfs was used. When looking where some of your memory has gone because some files are not directly mapped it is nice to have a hint as to why at run time. Doing it that way also works as comments for someone reading the code, and the compiler optimizes those strings away when DEBUG is not defined anyway. I did s/fail/bailout/ though, as those are not hard failures. The hard failures have no such debugging messages. [...] > It seems like this whole partial section should just go into a little > helper where the nonzero case is at the end of said helper to make it > readable. Also lots of magic numbers again, and generally a little > too much magic for the code to be easily understandable: why do you > operate on pointers casted to longs, increment in 8-byte steps? > Why is offset_in_page used for an operation that doesn't operate on > struct page at all? Any reason you can't just use memchr_inv? Ahhh... use memchr_inv is in fact exactly what I was looking for. Learn something every day. [...] > > + /* We failed to do a direct map, but normal paging is still possible */ > > + vma->vm_ops = &generic_file_vm_ops; > > Maybe let the mixedmap case fall through to this instead of having > a duplicate vm_ops assignment. The code flow is different and that makes it hard to have a common assignment in this case. Otherwise I've applied all your suggestions. Thanks for your comments. Very appreciated. Nicolas
WARNING: multiple messages have this Message-ID (diff)
From: Nicolas Pitre <nicolas.pitre@linaro.org> To: Christoph Hellwig <hch@infradead.org> Cc: Richard Weinberger <richard.weinberger@gmail.com>, Alexander Viro <viro@zeniv.linux.org.uk>, "linux-mm@kvack.org" <linux-mm@kvack.org>, linux-fsdevel <linux-fsdevel@vger.kernel.org>, "linux-embedded@vger.kernel.org" <linux-embedded@vger.kernel.org>, LKML <linux-kernel@vger.kernel.org>, Chris Brandt <Chris.Brandt@renesas.com> Subject: Re: [PATCH v4 4/5] cramfs: add mmap support Date: Thu, 5 Oct 2017 13:52:03 -0400 (EDT) [thread overview] Message-ID: <nycvar.YSQ.7.76.1710051203260.1693@knanqh.ubzr> (raw) In-Reply-To: <20171005071545.GA23364@infradead.org> On Thu, 5 Oct 2017, Christoph Hellwig wrote: > On Wed, Oct 04, 2017 at 04:47:52PM -0400, Nicolas Pitre wrote: > > The only downside so far is the lack of visibility from user space to > > confirm it actually works as intended. With the vma splitting approach > > you clearly see what gets directly mapped in /proc/*/maps thanks to > > remap_pfn_range() storing the actual physical address in vma->vm_pgoff. > > With VM_MIXEDMAP things are no longer visible. Any opinion for the best > > way to overcome this? > > Add trace points that allow you to trace it using trace-cmd, perf > or just tracefs? In memory constrained embedded environments those facilities are sometimes too big to be practical. And the /proc/*/maps content is static i.e. it is always there regardless of how many tasks you have and how long they've been running which makes it extremely handy. > > Anyway, here's a replacement for patch 4/5 below: > > This looks much better, and is about 100 lines less than the previous > version. More (mostly cosmetic) comments below: > [...] > > + fail_reason = "vma is writable"; > > + if (vma->vm_flags & VM_WRITE) > > + goto fail; > > The fail_reaosn is a rather unusable style, is there any good reason > why you need it here? We generall don't add a debug printk for every > pssible failure case. There are many things that might make your files not XIP and they're mostly related to how the file is mmap'd or how mkcramfs was used. When looking where some of your memory has gone because some files are not directly mapped it is nice to have a hint as to why at run time. Doing it that way also works as comments for someone reading the code, and the compiler optimizes those strings away when DEBUG is not defined anyway. I did s/fail/bailout/ though, as those are not hard failures. The hard failures have no such debugging messages. [...] > It seems like this whole partial section should just go into a little > helper where the nonzero case is at the end of said helper to make it > readable. Also lots of magic numbers again, and generally a little > too much magic for the code to be easily understandable: why do you > operate on pointers casted to longs, increment in 8-byte steps? > Why is offset_in_page used for an operation that doesn't operate on > struct page at all? Any reason you can't just use memchr_inv? Ahhh... use memchr_inv is in fact exactly what I was looking for. Learn something every day. [...] > > + /* We failed to do a direct map, but normal paging is still possible */ > > + vma->vm_ops = &generic_file_vm_ops; > > Maybe let the mixedmap case fall through to this instead of having > a duplicate vm_ops assignment. The code flow is different and that makes it hard to have a common assignment in this case. Otherwise I've applied all your suggestions. Thanks for your comments. Very appreciated. Nicolas -- 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:[~2017-10-05 17:52 UTC|newest] Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-09-27 23:32 [PATCH v4 0/5] cramfs refresh for embedded usage Nicolas Pitre 2017-09-27 23:32 ` Nicolas Pitre 2017-09-27 23:32 ` [PATCH v4 1/5] cramfs: direct memory access support Nicolas Pitre 2017-09-27 23:32 ` Nicolas Pitre 2017-10-01 8:29 ` Christoph Hellwig 2017-10-01 8:29 ` Christoph Hellwig 2017-10-01 22:27 ` Nicolas Pitre 2017-10-01 22:27 ` Nicolas Pitre 2017-10-03 14:59 ` Christoph Hellwig 2017-10-03 14:59 ` Christoph Hellwig 2017-10-03 15:06 ` Nicolas Pitre 2017-10-03 15:06 ` Nicolas Pitre 2017-10-03 14:43 ` Rob Herring 2017-10-03 14:43 ` Rob Herring 2017-10-03 14:58 ` Chris Brandt 2017-10-03 14:58 ` Chris Brandt 2017-09-27 23:32 ` [PATCH v4 2/5] cramfs: make cramfs_physmem usable as root fs Nicolas Pitre 2017-09-27 23:32 ` Nicolas Pitre 2017-09-27 23:32 ` [PATCH v4 3/5] cramfs: implement uncompressed and arbitrary data block positioning Nicolas Pitre 2017-09-27 23:32 ` Nicolas Pitre 2017-09-27 23:32 ` [PATCH v4 4/5] cramfs: add mmap support Nicolas Pitre 2017-09-27 23:32 ` Nicolas Pitre 2017-10-01 8:30 ` Christoph Hellwig 2017-10-01 8:30 ` Christoph Hellwig 2017-10-01 22:29 ` Nicolas Pitre 2017-10-01 22:29 ` Nicolas Pitre 2017-10-02 22:45 ` Richard Weinberger 2017-10-02 22:45 ` Richard Weinberger 2017-10-02 23:33 ` Nicolas Pitre 2017-10-02 23:33 ` Nicolas Pitre 2017-10-03 14:57 ` Christoph Hellwig 2017-10-03 14:57 ` Christoph Hellwig 2017-10-03 15:30 ` Nicolas Pitre 2017-10-03 15:30 ` Nicolas Pitre 2017-10-03 15:37 ` Christoph Hellwig 2017-10-03 15:37 ` Christoph Hellwig 2017-10-03 15:40 ` Nicolas Pitre 2017-10-03 15:40 ` Nicolas Pitre 2017-10-04 7:25 ` Christoph Hellwig 2017-10-04 7:25 ` Christoph Hellwig 2017-10-04 20:47 ` Nicolas Pitre 2017-10-04 20:47 ` Nicolas Pitre 2017-10-05 7:15 ` Christoph Hellwig 2017-10-05 7:15 ` Christoph Hellwig 2017-10-05 17:52 ` Nicolas Pitre [this message] 2017-10-05 17:52 ` Nicolas Pitre 2017-10-05 20:00 ` Chris Brandt 2017-10-05 20:00 ` Chris Brandt 2017-10-05 21:15 ` Nicolas Pitre 2017-10-05 21:15 ` Nicolas Pitre 2017-10-05 23:49 ` Chris Brandt 2017-10-05 23:49 ` Chris Brandt 2017-09-27 23:32 ` [PATCH v4 5/5] cramfs: rehabilitate it Nicolas Pitre 2017-09-27 23:32 ` Nicolas Pitre
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=nycvar.YSQ.7.76.1710051203260.1693@knanqh.ubzr \ --to=nicolas.pitre@linaro.org \ --cc=Chris.Brandt@renesas.com \ --cc=hch@infradead.org \ --cc=linux-embedded@vger.kernel.org \ --cc=linux-fsdevel@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=richard.weinberger@gmail.com \ --cc=viro@zeniv.linux.org.uk \ /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.