Some comments:
- some people have made arguments assuming that IO time is
separable from CPU time. In the current hardware, we need to busy
wait for IO in Linux (long story, ask dwmw2, basically the delay
required by the hardware is short enough that it slows down IO by
tenfold if we have to
mitch wrote:
On a related topic, I would like to see us start bundling the initrd
into the kernel image. It's certainly possible to do that with
existing
into? i'd rather see it simply concatenated,
By into, I mean in the same file.
The existing kernel mechanism
On 04/10/08 18:07 -0700, Deepak Saxena wrote:
- Embedded systems often use a suspend image to speedup boottime.
Basically load an image into memory and then jump into the
kernel as if we are resuming from firmware. Another approach
if we can't do a full suspend image this is to use the
On Mon, 6 Oct 2008, [EMAIL PROTECTED] wrote:
mitch wrote:
On a related topic, I would like to see us start bundling the initrd
into the kernel image. It's certainly possible to do that with
existing
into? i'd rather see it simply concatenated,
By into, I mean in the
On Oct 05 2008, at 10:50, Jim Gettys was caught saying:
On Sat, 2008-10-04 at 16:32 -1000, Mitch Bradley wrote:
I have considered something like that off and on. It's sort of nice to
have a definite length for the images. There are ways around that, but
they are a bit ugly at some
On Sat, 2008-10-04 at 16:32 -1000, Mitch Bradley wrote:
I have considered something like that off and on. It's sort of nice to
have a definite length for the images. There are ways around that, but
they are a bit ugly at some level. It's sort of a tossup at some level.
One difficultly
On Sat, 4 Oct 2008, Mitch Bradley wrote:
Deepak Saxena wrote:
On Oct 03 2008, at 07:34, Mitch Bradley was caught saying:
If
it is stored deocompressed to begin with on the filesystem, we
can simply read it into mem from flash and run. This would require
a few extra MiB of flash.
can you do the hash as you copy it? it should be pretty close to free at
that point (since the CPU is waiting for memory/flash access it can do the
hash calculationwhen it would otherwise be stalled)
According to my measurements the GeodeLX can fetch a new cache line (32
bytes) every
On Sun, 5 Oct 2008, NoiseEHC wrote:
can you do the hash as you copy it? it should be pretty close to free at
that point (since the CPU is waiting for memory/flash access it can do the
hash calculationwhen it would otherwise be stalled)
According to my measurements the GeodeLX can fetch a
Hi,
Then again, since ubifs mounts quickly, the largest reason for
partitioning we've had (to reduce boot time) evaporates. There may
be other reasons to want partitioning, given dynamic resizing a'la
lvm, however.
You don't mention the fundamental reason that we need
On Sun, 5 Oct 2008, NoiseEHC wrote:
can you do the hash as you copy it? it should be pretty close to
free at that point (since the CPU is waiting for memory/flash access
it can do the hash calculationwhen it would otherwise be stalled)
According to my measurements the GeodeLX can fetch
There is a C routine available for doing the initial read from the file
system. We don't have to do it from scratch...
Bull. Flag. Red
- Jim
On Sun, 2008-10-05 at 13:00 -0400, Chris Ball wrote:
Hi,
Then again, since ubifs mounts quickly, the largest reason
Memory to memory copy: 500 MB/s
Raw NAND FLASH read:20 MB/s
Security hash: 4 MB/s
So overlapping hash calculation with NAND FLASH read is of limited
value, and trying to overlap anything with memory copy is almost
certainly counterproductive.
This discussion seem to be
When I will finally have some time (currently I am working even on
weekends) I will finish my half made zlib decompression code.
Where is that Security hash's code?
Mitch Bradley wrote:
Memory to memory copy: 500 MB/s
Raw NAND FLASH read:20 MB/s
Security hash: 4 MB/s
So
NoiseEHC wrote:
When I will finally have some time (currently I am working even on
weekends) I will finish my half made zlib decompression code.
To what end? AFAIK the zlib decompression (both in OFW and in the OS)
is not one of the primary problem areas.
Where is that Security hash's
To what end? AFAIK the zlib decompression (both in OFW and in the OS)
is not one of the primary problem areas.
Changing fs read from CPU bound to IO bound would change a lot of
things, for example the boot could utilize a little bit of more
concurrency. Unfortunately we will only see its
mitch wrote:
Deepak Saxena wrote:
On Oct 04 2008, at 15:49, Mitch Bradley was caught saying:
c) Raw FLASH read time maxes out at 20 MB/sec. But you don't get that
speed from the filesystem; JFFS2 is good for between 5 and 10 MB/sec.
Considering all the intricacies of
NoiseEHC wrote:
To what end? AFAIK the zlib decompression (both in OFW and in the
OS) is not one of the primary problem areas.
Changing fs read from CPU bound to IO bound would change a lot of
things, for example the boot could utilize a little bit of more
concurrency. Unfortunately we
On a related topic, I would like to see us start bundling the initrd
into the kernel image. It's certainly possible to do that with existing
into? i'd rather see it simply concatenated,
By into, I mean in the same file.
The existing kernel mechanism that I have looked at involves
On Oct 03 2008, at 08:08, Mitch Bradley was caught saying:
neither of these require any changes to the Fedora stuff (I do this on
every system that I run, have done so with many different distros, and
never run into problems)
remember that you can still have modules for USB devices,
a) Some people argue that we shouldn't bother to speed up boot, because
suspend/resume optimization is more important. (I agree that S/R is
more important, but I wish that we could do both.)
Thank you all for your work on cutting down boot times.
I am interested in the use case where a
On Oct 03 2008, at 07:34, Mitch Bradley was caught saying:
Could somebody explain me whether [the 5 second boot] results are
applicable to the
XO, and how far are we from it, please?
Ticket http://dev.laptop.org/ticket/4349 details my and codyl's
experiments with speeding up
Deepak Saxena wrote:
On Oct 03 2008, at 07:34, Mitch Bradley was caught saying:
Could somebody explain me whether [the 5 second boot] results are
applicable to the
XO, and how far are we from it, please?
Ticket http://dev.laptop.org/ticket/4349 details my and codyl's
This depends pretty strongly on which Linux distribution you choose as
the basis for your USB key Sugar installation. The need to be
compatible with a wide range of different computers is going to be a
significant issue. If you have to deal with a lot of possibilities, you
need a lot of code
On Oct 04 2008, at 19:24, Deepak Saxena was caught saying:
On Oct 04 2008, at 15:49, Mitch Bradley was caught saying:
c) Raw FLASH read time maxes out at 20 MB/sec. But you don't get that
speed from the filesystem; JFFS2 is good for between 5 and 10 MB/sec.
Considering all the
Deepak Saxena wrote:
On Oct 04 2008, at 15:49, Mitch Bradley was caught saying:
c) Raw FLASH read time maxes out at 20 MB/sec. But you don't get that
speed from the filesystem; JFFS2 is good for between 5 and 10 MB/sec.
Considering all the intricacies of JFFS2, my best guess is that
On Oct 04 2008, at 16:32, Mitch Bradley was caught saying:
We can probably just get away with making all of /boot into a
romfs; however, do we even need to bother with a filesystem
representation of the images? We could have four partions (kernel0,
kernel1, initrd0, initrd1) that contain
Deepak Saxena wrote:
On Oct 04 2008, at 16:32, Mitch Bradley was caught saying:
We can probably just get away with making all of /boot into a
romfs; however, do we even need to bother with a filesystem
representation of the images? We could have four partions (kernel0,
kernel1,
Yes, but our biggest single component of boot time this instant is jffs2
mount (which happens twice during the boot sequence), not covered in
that work.
This is fixable in two ways; partially, by partitioning the flash (which
would remove one mount), or even better, by using Ubifs, which may be
On Fri, Oct 03, 2008 at 03:24:25PM +0200, NoiseEHC wrote:
If you somehow missed it, there is possible to boot Linux in 5 seconds
on an EeePC.
http://uk.youtube.com/watch?v=s7NxCM8ryF8
Here is the paper:
http://www.fenrus.org/plumbers_fastboot.ppt
Could somebody explain me whether these
The following articles on reducing linux boot times have recently
been published:
http://blog.crozat.net/2008/09/improving-boot-time-on-general-linux.html
http://www.bootchart.org/
http://lwn.net/Articles/299483/
http://broadcast.oreilly.com/2008/09/how-powertop-latencytop-and-fi.html
There
Could somebody explain me whether [the 5 second boot] results are applicable
to the
XO, and how far are we from it, please?
Ticket http://dev.laptop.org/ticket/4349 details my and codyl's
experiments with speeding up boot.
Between the two of us, we managed to shave off 23 seconds.
On Fri, 3 Oct 2008, Mitch Bradley wrote:
Could somebody explain me whether [the 5 second boot] results are applicable
to the
XO, and how far are we from it, please?
Ticket http://dev.laptop.org/ticket/4349 details my and codyl's
experiments with speeding up boot.
Between the two of us,
[EMAIL PROTECTED] wrote:
On Fri, 3 Oct 2008, Mitch Bradley wrote:
...
since the XO hardware is fixed, why would you ship a kernel that used
modules for any of the XO hardware? especially for anything that it
needs at boot time?
By and large, the required drivers are not modules. It's
On Fri, 3 Oct 2008, Mitch Bradley wrote:
[EMAIL PROTECTED] wrote:
On Fri, 3 Oct 2008, Mitch Bradley wrote:
...
since the XO hardware is fixed, why would you ship a kernel that used
modules for any of the XO hardware? especially for anything that it needs
at boot time?
By and large,
On Fri, 2008-10-03 at 11:32 -0700, [EMAIL PROTECTED] wrote:
On Fri, 3 Oct 2008, Mitch Bradley wrote:
[EMAIL PROTECTED] wrote:
On Fri, 3 Oct 2008, Mitch Bradley wrote:
if you don't need modules to boot, why do you need initrd? you should be
able to just do everything from the main
On Fri, 3 Oct 2008, Jeremy Katz wrote:
On Fri, 2008-10-03 at 11:32 -0700, [EMAIL PROTECTED] wrote:
On Fri, 3 Oct 2008, Mitch Bradley wrote:
[EMAIL PROTECTED] wrote:
On Fri, 3 Oct 2008, Mitch Bradley wrote:
if you don't need modules to boot, why do you need initrd? you should be
able to just
On Fri, 2008-10-03 at 11:49 -0700, [EMAIL PROTECTED] wrote:
On Fri, 3 Oct 2008, Jeremy Katz wrote:
[1] With the one[2] obvious exception of whatever is done in the initrd
takes time -- but if those things are moved later, they still take the
same time. And if they're not needed, don't do
On Fri, 3 Oct 2008, [EMAIL PROTECTED] wrote:
On Fri, 3 Oct 2008, Jeremy Katz wrote:
On Fri, 2008-10-03 at 11:32 -0700, [EMAIL PROTECTED] wrote:
On Fri, 3 Oct 2008, Mitch Bradley wrote:
[EMAIL PROTECTED] wrote:
On Fri, 3 Oct 2008, Mitch Bradley wrote:
if you don't need modules to boot, why
39 matches
Mail list logo
