On Mon, Jul 19, 2010 at 05:47:40PM +0100, Richard W.M. Jones wrote:
> On Mon, Jul 19, 2010 at 07:11:37PM +0300, Gleb Natapov wrote:
> > And there are such that cause cpu to stall for 6.5 seconds when you do
> > io to them? I never said that we should implement ISA or PCI device, I
> > don't know why you bring them here.
>
> Where is "6.5 seconds" coming from? That is the *total boot time*
> of the libguestfs appliance, and includes far far more than the
> time taken to do the memcpy.
>
> I timed the call to cpu_physical_memory_write, and it takes 115
> milliseconds with my patch (for an initrd which is 113 MB).
>
And how much time it takes to load it using string PIO? 1 second 115
millisecond? I thought 6.5 and 7.5 was image loading time, not total
boot time. Stalling vcpu execution for 115 millisecond may be unfortunate
but not as catastrophic as 6.5 seconds. But interface will be there for
everyone to use, so it may be eventually abused even more.
> > It should look like real DMA at least. The justification for it should
> > be better than "In our project we don't what to do this and we don't
> > what to do that so our initrd is 100M now, so why not add hack to qemu
> > to load it 1 second faster so we can grow it some more".
>
> Please don't make stuff up. We have a large initrd for perfectly good
> reasons which I have outlined in a previous email.
Those reasons does not look good for me at all. Cleaning up existing
distro is not much less work that creating basic distro with only things
you need, but result is much better. When I worked on embedded project
almost 10 years ago we tried to cleanup generic Red Hat Linux and result
was still huge. By building our own distro we were able to squeeze two
root partitions in 64M compressed. You also do not want to consider
putting things into cdrom because of some issues that should be
solvable.
--
Gleb.
