From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <13426df10802180910g45d2134cs7919137aa6f3661d@mail.gmail.com> Date: Mon, 18 Feb 2008 09:10:07 -0800 From: "ron minnich" To: "Fans of the OS Plan 9 from Bell Labs" <9fans@cse.psu.edu> Subject: Re: Page-aligned executables (Was re: [9fans] Non-stack-based calling conventions) In-Reply-To: <7871fcf50802180853v7473d507w991517014e3cb4bb@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <7871fcf50802180853v7473d507w991517014e3cb4bb@mail.gmail.com> Topicbox-Message-UUID: 5965fc86-ead3-11e9-9d60-3106f5b1d025 On Feb 18, 2008 8:53 AM, Joel C. Salomon wrote: > Ron mentioned that tidbit in his IWP9 talk about booting Plan 9 under > lguest. Lguest (or was it another virtualizer?) uses mmap so it can > load any arbitrary number of client kernels; 9l-produced ELF files > break that model. And with the execute in place support (XIP) it gets more interesting, and worth understanding, for reasons I'll mention below. IF you have an ext2-based RAM file system, and XIP is compiled in, then you can do the following: instead of mmap'ing the file, ext2 essentially says: "here's a pointer to the data you wanted, it's in memory, just use it, don't page it in because that would be a copy from memory to memory". Why's it matter? First, boot time speed. A talk I saw on a Linux-based car computer stated that their boot time goal was one second; Linux was only allowed a very small fraction of this time to be ready (200 milliseconds IIRC); XIP made a difference between meeting the time goals and not meeting them. Second, memory: on a 32 MB node, you really don't want two copies of every binary. So it's interesting to think about whether Plan 9 could boot a node in 200 ms on a StrongARM (500 mhz? I think so) or not. But I think XIP on a small RAM disk would not be impossible. ron