All of lore.kernel.org
 help / color / mirror / Atom feed
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>

  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: link
Be 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.