Re: [Qemu-devel] [patch] IDE busmaster DMA support

[Joe Batt]

On Mon, 2005-09-26 at 21:48 -0400, John Coiner wrote:
 Can anyone shed light on the potential performance to be realized? For 
 example, how long does a context switch take in the guest? If it takes 
 10ms (one disk seek) then there's probably no benefit to concurrent disk 
 IO. If a context switch takes 1ms, then the guest has opportunity to 
 make forward progress while awaiting an IDE interrupt.

I ran this code to time context switches:

#include sys/time.h
#include time.h
#include unistd.h
#include stdlib.h
#include stdio.h
#include string.h

int main(int argc, char *argv[]) {
  struct timeval start;
  gettimeofday(start, NULL);

  int fd[2];
  pipe(fd);

  int child = fork();

  int i, count = 10;
  char *msg = malloc(2);
  strcpy(msg, m);
  for (i = 0; i  count; i++) {
if (child) {
  if (write(fd[1], msg, 1) != 1)
fprintf(stderr, FAILURE\n);
} else {
  if (read(fd[0], msg, 1) != 1)
fprintf(stderr, FAILURE\n);
}
  }
  struct timeval end;
  gettimeofday(end, NULL);
  printf(%g microseconds/context switch\n, 
 (((end.tv_sec - start.tv_sec) * (double)100) +
end.tv_usec - start.tv_usec)/count);


  return 0;
}


On my dual 2.4 Ghz Xeon, I get the following timings.

host:~  ./yieldtest
2.35418 microseconds/context switch
2.35414 microseconds/context switch

KNOPPIX guest:  ./yieldtest
105.092 microseconds/context switch
105.184 microseconds/context switch

Is that what you are after?

-- 
Joe Batt [EMAIL PROTECTED]



___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] [patch] IDE busmaster DMA support

[Troy Benjegerdes]

On Mon, Sep 26, 2005 at 09:48:25PM -0400, John Coiner wrote:
 
 Hi,
 
 Here's another patch to enable IDE DMA:
 
   http://people.brandeis.edu/~jcoiner/qemu_idedma/qemu_dma_patch.html
 
 This patch, like Juergen Lock's earlier patch from which it is derived, 
 replaces the virtual PIIX3 IDE controller with a PIIX4.
 
 It applies cleanly to 0.7.2.
 
 This patch extends the Windows 2000 install hack to work for DMA also -- 
 I installed and ran Windows 2000 with DMA enabled.
 
 It'd be cool if QEMU supported nonblocking disk access -- if it would 
 let the guest resume running currently, while waiting for the disk to 
 finish seeking. This patch is a first step toward concurrent IO, which 
 would probably have to use busmastering DMA transfers to be efficient, 
 if it's going to be efficient at all.
 
 Do people have ideas about how to implement concurrent IO? I have a 
 couple hazy ideas...
 
 Can anyone shed light on the potential performance to be realized? For 
 example, how long does a context switch take in the guest? If it takes 
 10ms (one disk seek) then there's probably no benefit to concurrent disk 
 IO. If a context switch takes 1ms, then the guest has opportunity to 
 make forward progress while awaiting an IDE interrupt.

I would strongly suggest attempting to make use of the Linux Async I/O
support.. this way the data from disk could be placed directly in
address space of the guest OS. 

Personally, I'd love to see nonblocking disk IO. I've tried running Qemu
using a disk image on an AFS filesystem, and having the guest be able to
continue while the filesystem is fetching data from the network would
make things much nicer.


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel