Re: [Qemu-devel] Anyone seeing huge slowdown launching qemu with Linux 2.6.35?

[Anthony Liguori]

On 08/03/2010 09:53 AM, Richard W.M. Jones wrote:
> On Tue, Aug 03, 2010 at 05:38:25PM +0300, Avi Kivity wrote:
>    
> > The time will only continue to grow as you add features and as the
> > distro bloats naturally.
> >
> > Much better to create it once and only update it if some dependent
> > file changes (basically the current on-the-fly code + save a list of
> > file timestamps).
> >      
> This applies to both cases, the initrd could also be saved, so:
>
>    
> > > Total saving: 115ms.
> > >        
> > 815 ms by my arithmetic.
> >      
> no, not true, 115ms.
>
>    
> > You also save 3*N-2*P memory where N is the size of your initrd and
> > P is the actual amount used by the guest.
> >      
> Can you explain this?
>
>    
> > Loading a file into memory is plenty fast if you use the standard
> > interfaces.  -kernel -initrd is a specialized interface.
> >      
> Why bother with any command line options at all?  After all, they keep
> changing and causing problems for qemu's users ...  Apparently we're
> all doing stuff "wrong", in ways that are never explained by the
> developers.
>    

Let's be fair.  I think we've all agreed to adjust the fw_cfg interface 
to implement DMA.  The only requirement was that the DMA operation not 
be triggered from a single port I/O but rather based on a polling 
operation which better fits the way real hardware works.

Is this a regression?  Probably.  But performance regressions that 
result from correctness fixes don't get reverted.  We have to find an 
approach to improve performance without impacting correctness.

That said, the general view of -kernel/-append is that these are 
developer options and we don't really look at it as a performance 
critical interface.  We could do a better job of communicating this to 
users but that's true of most of the features we support.

Regards,

Anthony Liguori

> Rich.
>
>