On Mon, Jul 19, 2010 at 09:57:02AM +0200, Alexander Graf wrote:
>
> On 19.07.2010, at 09:51, Gleb Natapov wrote:
>
> > On Mon, Jul 19, 2010 at 09:40:18AM +0200, Alexander Graf wrote:
> >>
> >> On 19.07.2010, at 09:33, Gleb Natapov wrote:
> >>
> >>> On Mon, Jul 19, 2010 at 08:28:02AM +0100, Richard W.M. Jones wrote:
> >>>> On Mon, Jul 19, 2010 at 09:23:56AM +0300, Gleb Natapov wrote:
> >>>>> That what I am warring about too. If we are adding device we have to be
> >>>>> sure such device can actually exist on real hw too otherwise we may have
> >>>>> problems later.
> >>>>
> >>>> I don't understand why the constraints of real h/w have anything to do
> >>>> with this. Can you explain?
> >>>>
> >>> Each time we do something not architectural it cause us troubles later.
> >>> So constraints of real h/w is our constrains to.
> >>>
> >>>>> Also 1 second on 100M file does not look like huge gain to me.
> >>>>
> >>>> Every second counts. We're trying to get libguestfs boot times down
> >>>> from 8-12 seconds to 4-5 seconds. For many cases it's an interactive
> >>>> program.
> >>>>
> >>> So what about making initrd smaller? I remember managing two
> >>> distribution in 64M flash in embedded project.
> >>
> >> Having a huge initrd basically helps in reusing a lot of existing code. We
> >> do the same - in general the initrd is just a subset of the applications
> >> of the host OS. And if you start putting perl or the likes into it, it
> >> becomes big.
> >>
> > Why not provide small disk/cdrom with all those utilities installed?
>
> Because - if the loading is done fast - this way everything's in RAM
> instantly. And you still have all devices available for use inside the system
> - that makes enumeration a lot easier. There are several reasons why and I
> don't think we should force different ways on people just because one
> component of our system is ineffective.
>
Loading huge initrd on real HW takes noticeably longer time that small
one, so I would say that it is your design that is to blame here, not
KVM.
> >
> >> I guess the best thing for now really is to try and see which code paths
> >> insb goes along. It should really be coalesced.
> >>
> > It is coalesced to a certain extent (reenter guest every 1024 bytes,
> > read from userspace page at a time). You need to continue injecting
> > interrupt into a guest during long string operation and checking
> > exception condition on a page boundaries.
>
> That still sounds slow. So yeah, adding DMA is probably the right way to go.
> But then again - if we model it after real hw it would be asynchronous,
> giving us an interrupt, causing even more headache. Ugh.
>
> Can't we just ignore real hw constraints here and have it available in guest
> ram once one particular PIO is done? No bus master, no interrupts, but full
> speed and simplicity/atomicity which also helps migration.
>
We shouldn't add devices that work not like real HW to speed up some
pathological cases (and are slow on real HW too).
--
Gleb.
