From: Nicolas Pitre <nicolas.pitre@linaro.org> To: Chris Brandt <Chris.Brandt@renesas.com> Cc: Christoph Hellwig <hch@infradead.org>, 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 17:15:28 -0400 (EDT) [thread overview] Message-ID: <nycvar.YSQ.7.76.1710051707540.1693@knanqh.ubzr> (raw) In-Reply-To: <SG2PR06MB11655D2F14AC44BA565848788A700@SG2PR06MB1165.apcprd06.prod.outlook.com> On Thu, 5 Oct 2017, Chris Brandt wrote: > On Wednesday, October 04, 2017, Nicolas Pitre wrote: > > 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] Do you have the same amount of free memory once booted in both cases? > Regardless, from a functional standpoint: > > Tested-by: Chris Brandt <chris.brandt@renesas.com> Thanks. > 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 Yeah, that was necessary because split_vma() wasn't exported to modules. Now split_vma() is no longer used so the no-module restriction has also been removed. Nicolas
WARNING: multiple messages have this Message-ID (diff)
From: Nicolas Pitre <nicolas.pitre@linaro.org> To: Chris Brandt <Chris.Brandt@renesas.com> Cc: Christoph Hellwig <hch@infradead.org>, 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 17:15:28 -0400 (EDT) [thread overview] Message-ID: <nycvar.YSQ.7.76.1710051707540.1693@knanqh.ubzr> (raw) In-Reply-To: <SG2PR06MB11655D2F14AC44BA565848788A700@SG2PR06MB1165.apcprd06.prod.outlook.com> On Thu, 5 Oct 2017, Chris Brandt wrote: > On Wednesday, October 04, 2017, Nicolas Pitre wrote: > > 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] Do you have the same amount of free memory once booted in both cases? > Regardless, from a functional standpoint: > > Tested-by: Chris Brandt <chris.brandt@renesas.com> Thanks. > 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 Yeah, that was necessary because split_vma() wasn't exported to modules. Now split_vma() is no longer used so the no-module restriction has also been removed. 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 21:15 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 2017-10-05 20:00 ` Chris Brandt 2017-10-05 21:15 ` Nicolas Pitre [this message] 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.1710051707540.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.