From: Chris Brandt <Chris.Brandt@renesas.com> To: Nicolas Pitre <nicolas.pitre@linaro.org>, 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> Subject: RE: [PATCH v4 4/5] cramfs: add mmap support Date: Thu, 5 Oct 2017 20:00:07 +0000 [thread overview] Message-ID: <SG2PR06MB11655D2F14AC44BA565848788A700@SG2PR06MB1165.apcprd06.prod.outlook.com> (raw) In-Reply-To: <nycvar.YSQ.7.76.1710041608460.1693@knanqh.ubzr> On Wednesday, October 04, 2017, Nicolas Pitre wrote: > On Wed, 4 Oct 2017, Christoph Hellwig wrote: > > > As said in my last mail: look at the VM_MIXEDMAP flag and how it is > > used by DAX, and you'll get out of the vma splitting business in the > > fault path. > > Alright, it appears to work. > > 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? > > Anyway, here's a replacement for patch 4/5 below: > > ----- >8 > Subject: cramfs: add mmap support > > When cramfs_physmem is used then we have the opportunity to map files > directly from ROM, directly into user space, saving on RAM usage. > This gives us Execute-In-Place (XIP) support. Tested on my setup: * Cortex A9 (with MMU) * CONFIG_XIP_KERNEL=y * booted with XIP CRAMFS as my rootfs * all apps and libraries marked as XIP in my cramfs image So far, functionally it seems to work the same as [PATCH v4 4/5]. As Nicolas said, before you could easily see that all my apps and libraries were XIP from Flash: $ cat /proc/self/maps 00008000-000a1000 r-xp 1b005000 00:0c 18192 /bin/busybox 000a9000-000aa000 rw-p 00099000 00:0c 18192 /bin/busybox 000aa000-000ac000 rw-p 00000000 00:00 0 [heap] b6e69000-b6f42000 r-xp 1b0bc000 00:0c 766540 /lib/libc-2.18-2013.10.so b6f42000-b6f4a000 ---p 1b195000 00:0c 766540 /lib/libc-2.18-2013.10.so b6f4a000-b6f4c000 r--p 000d9000 00:0c 766540 /lib/libc-2.18-2013.10.so b6f4c000-b6f4d000 rw-p 000db000 00:0c 766540 /lib/libc-2.18-2013.10.so b6f4d000-b6f50000 rw-p 00000000 00:00 0 b6f50000-b6f67000 r-xp 1b0a4000 00:0c 670372 /lib/ld-2.18-2013.10.so b6f6a000-b6f6b000 rw-p 00000000 00:00 0 b6f6c000-b6f6e000 rw-p 00000000 00:00 0 b6f6e000-b6f6f000 r--p 00016000 00:0c 670372 /lib/ld-2.18-2013.10.so b6f6f000-b6f70000 rw-p 00017000 00:0c 670372 /lib/ld-2.18-2013.10.so beac0000-beae1000 rw-p 00000000 00:00 0 [stack] bebc9000-bebca000 r-xp 00000000 00:00 0 [sigpage] ffff0000-ffff1000 r-xp 00000000 00:00 0 [vectors] But now just busybox looks like it's XIP: $ cat /proc/self/maps 00008000-000a1000 r-xp 1b005000 00:0c 18192 /bin/busybox 000a9000-000aa000 rw-p 00099000 00:0c 18192 /bin/busybox 000aa000-000ac000 rw-p 00000000 00:00 0 [heap] b6e4d000-b6f26000 r-xp 00000000 00:0c 766540 /lib/libc-2.18-2013.10.so b6f26000-b6f2e000 ---p 000d9000 00:0c 766540 /lib/libc-2.18-2013.10.so b6f2e000-b6f30000 r--p 000d9000 00:0c 766540 /lib/libc-2.18-2013.10.so b6f30000-b6f31000 rw-p 000db000 00:0c 766540 /lib/libc-2.18-2013.10.so b6f31000-b6f34000 rw-p 00000000 00:00 0 b6f34000-b6f4b000 r-xp 00000000 00:0c 670372 /lib/ld-2.18-2013.10.so b6f4e000-b6f4f000 rw-p 00000000 00:00 0 b6f50000-b6f52000 rw-p 00000000 00:00 0 b6f52000-b6f53000 r--p 00016000 00:0c 670372 /lib/ld-2.18-2013.10.so b6f53000-b6f54000 rw-p 00017000 00:0c 670372 /lib/ld-2.18-2013.10.so bec93000-becb4000 rw-p 00000000 00:00 0 [stack] befad000-befae000 r-xp 00000000 00:00 0 [sigpage] ffff0000-ffff1000 r-xp 00000000 00:00 0 [vectors] Regardless, from a functional standpoint: Tested-by: Chris Brandt <chris.brandt@renesas.com> Just FYI, the previous [PATCH v4 4/5] also included this (which was the only real difference between v3 and v4): diff --git a/fs/cramfs/Kconfig b/fs/cramfs/Kconfig index 5b4e0b7e13..306549be25 100644 --- a/fs/cramfs/Kconfig +++ b/fs/cramfs/Kconfig @@ -30,7 +30,7 @@ config CRAMFS_BLOCKDEV config CRAMFS_PHYSMEM bool "Support CramFs image directly mapped in physical memory" - depends on CRAMFS + depends on CRAMFS = y default y if !CRAMFS_BLOCKDEV help This option allows the CramFs driver to load data directly from Chris
WARNING: multiple messages have this Message-ID (diff)
From: Chris Brandt <Chris.Brandt@renesas.com> To: Nicolas Pitre <nicolas.pitre@linaro.org>, 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> Subject: RE: [PATCH v4 4/5] cramfs: add mmap support Date: Thu, 5 Oct 2017 20:00:07 +0000 [thread overview] Message-ID: <SG2PR06MB11655D2F14AC44BA565848788A700@SG2PR06MB1165.apcprd06.prod.outlook.com> (raw) In-Reply-To: <nycvar.YSQ.7.76.1710041608460.1693@knanqh.ubzr> On Wednesday, October 04, 2017, Nicolas Pitre wrote: > On Wed, 4 Oct 2017, Christoph Hellwig wrote: > > > As said in my last mail: look at the VM_MIXEDMAP flag and how it is > > used by DAX, and you'll get out of the vma splitting business in the > > fault path. > > Alright, it appears to work. > > 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? > > Anyway, here's a replacement for patch 4/5 below: > > ----- >8 > Subject: cramfs: add mmap support > > When cramfs_physmem is used then we have the opportunity to map files > directly from ROM, directly into user space, saving on RAM usage. > This gives us Execute-In-Place (XIP) support. Tested on my setup: * Cortex A9 (with MMU) * CONFIG_XIP_KERNEL=y * booted with XIP CRAMFS as my rootfs * all apps and libraries marked as XIP in my cramfs image So far, functionally it seems to work the same as [PATCH v4 4/5]. As Nicolas said, before you could easily see that all my apps and libraries were XIP from Flash: $ cat /proc/self/maps 00008000-000a1000 r-xp 1b005000 00:0c 18192 /bin/busybox 000a9000-000aa000 rw-p 00099000 00:0c 18192 /bin/busybox 000aa000-000ac000 rw-p 00000000 00:00 0 [heap] b6e69000-b6f42000 r-xp 1b0bc000 00:0c 766540 /lib/libc-2.18-2013.10.so b6f42000-b6f4a000 ---p 1b195000 00:0c 766540 /lib/libc-2.18-2013.10.so b6f4a000-b6f4c000 r--p 000d9000 00:0c 766540 /lib/libc-2.18-2013.10.so b6f4c000-b6f4d000 rw-p 000db000 00:0c 766540 /lib/libc-2.18-2013.10.so b6f4d000-b6f50000 rw-p 00000000 00:00 0 b6f50000-b6f67000 r-xp 1b0a4000 00:0c 670372 /lib/ld-2.18-2013.10.so b6f6a000-b6f6b000 rw-p 00000000 00:00 0 b6f6c000-b6f6e000 rw-p 00000000 00:00 0 b6f6e000-b6f6f000 r--p 00016000 00:0c 670372 /lib/ld-2.18-2013.10.so b6f6f000-b6f70000 rw-p 00017000 00:0c 670372 /lib/ld-2.18-2013.10.so beac0000-beae1000 rw-p 00000000 00:00 0 [stack] bebc9000-bebca000 r-xp 00000000 00:00 0 [sigpage] ffff0000-ffff1000 r-xp 00000000 00:00 0 [vectors] But now just busybox looks like it's XIP: $ cat /proc/self/maps 00008000-000a1000 r-xp 1b005000 00:0c 18192 /bin/busybox 000a9000-000aa000 rw-p 00099000 00:0c 18192 /bin/busybox 000aa000-000ac000 rw-p 00000000 00:00 0 [heap] b6e4d000-b6f26000 r-xp 00000000 00:0c 766540 /lib/libc-2.18-2013.10.so b6f26000-b6f2e000 ---p 000d9000 00:0c 766540 /lib/libc-2.18-2013.10.so b6f2e000-b6f30000 r--p 000d9000 00:0c 766540 /lib/libc-2.18-2013.10.so b6f30000-b6f31000 rw-p 000db000 00:0c 766540 /lib/libc-2.18-2013.10.so b6f31000-b6f34000 rw-p 00000000 00:00 0 b6f34000-b6f4b000 r-xp 00000000 00:0c 670372 /lib/ld-2.18-2013.10.so b6f4e000-b6f4f000 rw-p 00000000 00:00 0 b6f50000-b6f52000 rw-p 00000000 00:00 0 b6f52000-b6f53000 r--p 00016000 00:0c 670372 /lib/ld-2.18-2013.10.so b6f53000-b6f54000 rw-p 00017000 00:0c 670372 /lib/ld-2.18-2013.10.so bec93000-becb4000 rw-p 00000000 00:00 0 [stack] befad000-befae000 r-xp 00000000 00:00 0 [sigpage] ffff0000-ffff1000 r-xp 00000000 00:00 0 [vectors] Regardless, from a functional standpoint: Tested-by: Chris Brandt <chris.brandt@renesas.com> Just FYI, the previous [PATCH v4 4/5] also included this (which was the only real difference between v3 and v4): diff --git a/fs/cramfs/Kconfig b/fs/cramfs/Kconfig index 5b4e0b7e13..306549be25 100644 --- a/fs/cramfs/Kconfig +++ b/fs/cramfs/Kconfig @@ -30,7 +30,7 @@ config CRAMFS_BLOCKDEV config CRAMFS_PHYSMEM bool "Support CramFs image directly mapped in physical memory" - depends on CRAMFS + depends on CRAMFS = y default y if !CRAMFS_BLOCKDEV help This option allows the CramFs driver to load data directly from Chris -- 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 20:05 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 2017-10-05 17:52 ` Nicolas Pitre 2017-10-05 20:00 ` Chris Brandt [this message] 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=SG2PR06MB11655D2F14AC44BA565848788A700@SG2PR06MB1165.apcprd06.prod.outlook.com \ --to=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=nicolas.pitre@linaro.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.