coLinux benchmarks

coLinux benchmarks

[Dan Aloni]

Hello,

Today I ran some dbench2 benchmarks in order to test coLinux's
(http://www.colinux.org) virtual disk I/O performance.

I'm cross-posting this message to the LKML, as I know that on that
list there are some benchmarking experts or other people who may 
find this interesting.

This is the output from a coLinux 2.4.25 guest VM configured with 
128MB RAM running on a Linux 2.6.3 (BK) host that has a total of 
256MB RAM. The host machine has a Mobile Intel Celeron CPU (2.20GHz). 
All filesystems used are ext3.

    colinux:/home/dax# dbench 5 -s -S
    5 clients started
       0     62477  10.01 MB/sec
    Throughput 10.0026 MB/sec (sync open) (sync dirs) 5 procs

    colinux:/home/dax# dbench 5 -s -S
    5 clients started
       0     62477  10.43 MB/sec
    Throughput 10.4262 MB/sec (sync open) (sync dirs) 5 procs

    colinux:/home/dax# dbench 5 -s -S
    5 clients started
       0     62477  10.90 MB/sec
    Throughput 10.8926 MB/sec (sync open) (sync dirs) 5 procs


I then ran the same thing on the host itself, *without* the 
coLinux VM running in the background:

    hostile17:~/colinux# dbench 5 -s -S
    5 clients started
       0     62477  5.08 MB/sec
    Throughput 5.07573 MB/sec (sync open) (sync dirs) 5 procs
    
    hostile17:~/colinux# dbench 5 -s -S
    5 clients started
       0     62477  5.13 MB/sec
    Throughput 5.12705 MB/sec (sync open) (sync dirs) 5 procs


The VM shows better results than the host. What gives? Perhaps
it is because of the combination of the host and guest's buffer 
cache? I'd like to know about more percise benchmarking methods 
for VMs.

-- 
Dan Aloni
Cooperative Linux, lead developer
da-x@colinux.org

Re: coLinux benchmarks

[Christoph Hellwig]

> The VM shows better results than the host. What gives? Perhaps
> it is because of the combination of the host and guest's buffer 
> cache? I'd like to know about more percise benchmarking methods 
> for VMs.

How are the virtual disks for the VM implemented?  If you're doing
direct I/O these numbers are indeed strange.  If not OTOH that's
expected because even synchronous I/O in the guest is actually
async which makes it a lot faster.

Re: coLinux benchmarks

[Dan Aloni]

On Mon, Apr 05, 2004 at 02:30:56PM +0100, Christoph Hellwig wrote:
> > The VM shows better results than the host. What gives? Perhaps
> > it is because of the combination of the host and guest's buffer 
> > cache? I'd like to know about more percise benchmarking methods 
> > for VMs.
> 
> How are the virtual disks for the VM implemented?  If you're doing
> direct I/O these numbers are indeed strange.  If not OTOH that's
> expected because even synchronous I/O in the guest is actually
> async which makes it a lot faster.

The virtual block device driver in coLinux, named cobd, is synchronous 
with the host OS highest level read()/write() functions, which 
means e.g. for a READ block I/O request in the guest, 
filp->f_op->read() is called on an open 'struct file' in the host. 
If the call blocks, the entire guest VM blocks on it. 

So, according to this, any type of I/O in the guest means synchronous 
I/O in the host unless the data is already in the guest's buffer cache.

It's not really the implementation I am planning to stick to, but 
it sure was very easy to implement. 

BTW, the block device on the host side can be a file or any 
device that exposes read()/write() interfaces to userspace. In 
this benchmarking case it is a 3GB file that hosts an image of 
an ext3 filesystem.

-- 
Dan Aloni
da-x@colinux.org

Re: [coLinux-devel] coLinux benchmarks

[Eyal Lotem]

Hey, I stumbled upon this when checking my mail :)

I think the reason may be that Windows is using the
disks better and making access faster. Perhaps DMA
acceleration or some other feature is turned off on
the Linux host side, making disk access slower on the
Linux side.

Then again, that could only explain the first run of
the benchmark and not the cached runs.  Maybe some bug
in Linux's caching/buffering?

--- Dan Aloni <da-x@colinux.org> wrote:
> Hello,
> 
> Today I ran some dbench2 benchmarks in order to test
> coLinux's
> (http://www.colinux.org) virtual disk I/O
> performance.
> 
> I'm cross-posting this message to the LKML, as I
> know that on that
> list there are some benchmarking experts or other
> people who may 
> find this interesting.
> 
> This is the output from a coLinux 2.4.25 guest VM
> configured with 
> 128MB RAM running on a Linux 2.6.3 (BK) host that
> has a total of 
> 256MB RAM. The host machine has a Mobile Intel
> Celeron CPU (2.20GHz). 
> All filesystems used are ext3.
> 
>     colinux:/home/dax# dbench 5 -s -S
>     5 clients started
>        0     62477  10.01 MB/sec
>     Throughput 10.0026 MB/sec (sync open) (sync
> dirs) 5 procs
> 
>     colinux:/home/dax# dbench 5 -s -S
>     5 clients started
>        0     62477  10.43 MB/sec
>     Throughput 10.4262 MB/sec (sync open) (sync
> dirs) 5 procs
> 
>     colinux:/home/dax# dbench 5 -s -S
>     5 clients started
>        0     62477  10.90 MB/sec
>     Throughput 10.8926 MB/sec (sync open) (sync
> dirs) 5 procs
> 
> 
> I then ran the same thing on the host itself,
> *without* the 
> coLinux VM running in the background:
> 
>     hostile17:~/colinux# dbench 5 -s -S
>     5 clients started
>        0     62477  5.08 MB/sec
>     Throughput 5.07573 MB/sec (sync open) (sync
> dirs) 5 procs
>     
>     hostile17:~/colinux# dbench 5 -s -S
>     5 clients started
>        0     62477  5.13 MB/sec
>     Throughput 5.12705 MB/sec (sync open) (sync
> dirs) 5 procs
> 
> 
> The VM shows better results than the host. What
> gives? Perhaps
> it is because of the combination of the host and
> guest's buffer 
> cache? I'd like to know about more percise
> benchmarking methods 
> for VMs.
> 
> -- 
> Dan Aloni
> Cooperative Linux, lead developer
> da-x@colinux.org
> 
> 
>
-------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux
> Tutorials
> Free Linux tutorial presented by Daniel Robbins,
> President and CEO of
> GenToo technologies. Learn everything from
> fundamentals to system
>
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> coLinux-devel mailing list
> coLinux-devel@lists.sourceforge.net
>
https://lists.sourceforge.net/lists/listinfo/colinux-devel


__________________________________
Do you Yahoo!?
Yahoo! Small Business $15K Web Design Giveaway 
http://promotions.yahoo.com/design_giveaway/

Re: [coLinux-devel] coLinux benchmarks

[Dan Aloni]

On Mon, Apr 05, 2004 at 01:11:39PM -0700, Eyal Lotem wrote:

> I think the reason may be that Windows is using the
> disks better and making access faster. Perhaps DMA
> acceleration or some other feature is turned off on
> the Linux host side, making disk access slower on the
> Linux side.

No Windows was involved with these benchmarks in any way. I ran 
coLinux on Linux.

-- 
Dan Aloni
da-x@colinux.org

Re: [coLinux-devel] coLinux benchmarks

[Ian C. Blenke]

On Tue, Apr 06, 2004 at 12:22:56AM +0200, Dan Aloni wrote:
> On Mon, Apr 05, 2004 at 01:11:39PM -0700, Eyal Lotem wrote:
> 
> > I think the reason may be that Windows is using the
> > disks better and making access faster. Perhaps DMA
> > acceleration or some other feature is turned off on
> > the Linux host side, making disk access slower on the
> > Linux side.
> 
> No Windows was involved with these benchmarks in any way. I ran 
> coLinux on Linux.

You ran coLinux on a Linux host? Perhaps I've missed something on the list..
is there a native Linux kernel port now? An alternative to User Mode Linux
is a rather big thing for me.

- Ian C. Blenke <ian@blenke.com>

Re: [coLinux-devel] coLinux benchmarks

[Dan Aloni]

On Tue, Apr 06, 2004 at 09:45:49AM -0400, Ian C. Blenke wrote:
> On Tue, Apr 06, 2004 at 12:22:56AM +0200, Dan Aloni wrote:
> > On Mon, Apr 05, 2004 at 01:11:39PM -0700, Eyal Lotem wrote:
> > 
> > > I think the reason may be that Windows is using the
> > > disks better and making access faster. Perhaps DMA
> > > acceleration or some other feature is turned off on
> > > the Linux host side, making disk access slower on the
> > > Linux side.
> > 
> > No Windows was involved with these benchmarks in any way. I ran 
> > coLinux on Linux.
> 
> You ran coLinux on a Linux host? Perhaps I've missed something on the list..
> is there a native Linux kernel port now? An alternative to User Mode Linux
> is a rather big thing for me.

Yes, it's an alternative to User Mode Linux, thought it's a bit
early and doesn't have all the wide range of support tools and 
nifty stuff that UML has.

-- 
Dan Aloni
da-x@colinux.org

ReactOS and CoLinux status

[Steven Edwards]

Hello All,

If you want to run Linux and have your Windows device drivers then this
message is for you.

I just wanted to give all of you a update on our work to get CoLinux
working on ReactOS. Where it stands right now it looks like ReactOS
will be able to run CoLinux quite soon. We still have some issues with
running Cygwin applications so we need some help either fixing that or
we need to see if the CoLinux deamon can be built linking to msvcrt
rather than cygwin. Other than this the only show stopper we have atm
is our TCP/IP stack is still under heavy development and will not be
ready to run the Xserver and Linux network applications for another few
months.

Thanks
Steven


__________________________________
Do you Yahoo!?
Yahoo! Small Business $15K Web Design Giveaway 
http://promotions.yahoo.com/design_giveaway/