All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rob Gardner <rob.gardner@hp.com>
To: George Dunlap <dunlapg@umich.edu>
Cc: xen-tools@lists.xensource.com, xen-devel@lists.xensource.com,
	xen-users@lists.xensource.com,
	rickey berkeley <rickey.berkeley@gmail.com>
Subject: Re: Hi,something about the xentrace tool
Date: Sun, 18 Jun 2006 23:00:53 -0600	[thread overview]
Message-ID: <44962F85.4060005@hp.com> (raw)
In-Reply-To: <de76405a0606181806y4d08998ua680342c561be6d0@mail.gmail.com>

George Dunlap wrote:
>
> There's no copying from the HV to the xentrace process.  But there is
> copying from xentrace to the dom0 kernel for the output file.  Some
> copying is necessary right now, because rather than writing out the
> pages verbatim, xentrace writes out the pcpu before writing out each
> record:
>
> void write_rec(unsigned int cpu, struct t_rec *rec, FILE *out)
> {
>    size_t written = 0;
>    written += fwrite(&cpu, sizeof(cpu), 1, out);
>    written += fwrite(rec, sizeof(*rec), 1, out);
>    if ( written != 2 )
>    {
>        PERROR("Failed to write trace record");
>        exit(EXIT_FAILURE);
>    }
> }
>
> If we wanted to make it zero copy all the way from the HV to the disk,
> we could have the xentrace process one stream per cpu, and do
> whatever's necessary to use DMA.  (Does anyone know if O_DIRECT will
> do direct DMA, or if one would have to use a raw disk?) 


So you're saying if we didn't have to write the cpu number, then we 
could bypass stdio, and directly do a write() using the trace buffer? 
And this would be better because it would avoid a memory to memory copy, 
and use DMA immediately on the trace buffer memory? Do I understand you 
correctly? Assuming this is what you mean, allow me to correct a slight 
logic flaw. Stdio is there for a reason; Doing lots of raw I/O using 
very small buffers is highly inefficient. There's the overhead of kernel 
entry/exit and of setting up and tearing down DMA transactions. And 
writing to a block device will result in I/O's that are multiples of the 
devices' block size, so writing a 32 byte trace record will probably 
cause a 512-byte block to actually be written to disk. So bypassing 
stdio in this case will result in lots more disk accesses, lots more dma 
setup/teardown, and lots more system calls. In other words, the 
performance is going to horrible. The Stdio library greatly reduces all 
this overhead by buffering stuff in memory until there's enough to make 
a genuine I/O relatively efficient. In this case, the memory copies are 
intentional and beneficial; We do not want to eliminate them in our 
quest for "zero copy".

Rob

  reply	other threads:[~2006-06-19  5:00 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-06-15  7:06 Hi,something about the xentrace tool Ian Pratt
2006-06-15  8:58 ` [Xen-devel] " rickey berkeley
2006-06-15 17:03   ` Rob Gardner
2006-06-15 18:20     ` George Dunlap 
2006-06-15 18:28       ` George Dunlap 
2006-06-15 18:53       ` Rob Gardner
2006-06-19  1:06         ` George Dunlap 
2006-06-19  5:00           ` Rob Gardner [this message]
2006-06-19 14:02             ` George Dunlap 
2006-06-19 17:19               ` Rob Gardner
2006-06-21 19:02                 ` George Dunlap 
2006-06-15 16:41 ` Rob Gardner
  -- strict thread matches above, loose matches on Subject: below --
2006-06-19  7:14 Ian Pratt
2006-06-16 14:11 Ian Pratt
2006-06-16 16:56 ` Rob Gardner
2006-06-11 13:17 rickey berkeley
2006-06-12 15:17 ` George Dunlap 
2006-06-12 15:30 ` Ryan Harper
2006-06-13 17:11   ` rickey berkeley
2006-06-13 17:25     ` Rob Gardner
2006-06-14  3:47       ` NAHieu
2006-06-14 16:06         ` Rob Gardner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=44962F85.4060005@hp.com \
    --to=rob.gardner@hp.com \
    --cc=dunlapg@umich.edu \
    --cc=rickey.berkeley@gmail.com \
    --cc=xen-devel@lists.xensource.com \
    --cc=xen-tools@lists.xensource.com \
    --cc=xen-users@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.