From: Rob Gardner <rob.gardner@hp.com>
To: rickey berkeley <rickey.berkeley@gmail.com>
Cc: xen-tools@lists.xensource.com, xen-devel@lists.xensource.com,
xen-users@lists.xensource.com
Subject: Re: Hi,something about the xentrace tool
Date: Thu, 15 Jun 2006 11:03:29 -0600 [thread overview]
Message-ID: <449192E1.4080808@hp.com> (raw)
In-Reply-To: <8061f8830606150158m35f11025t43c3fa962ccd6679@mail.gmail.com>
rickey berkeley wrote:
>
> so,dose this mechanisms will effect the system performance
> evidently?as we know ,copy huge raw data from kernel space to user
> space will exhaust so much efficiency and system resource.
I wouldn't call the amount of data 'huge'. Even on a very busy system,
where there are thousands of trace records being generated every second,
that's still a pretty small amount of data. (The size of a trace record
is something like 50 or 60 bytes.) Also, the data is not "copied" from
kernel space to user space. There is a shared memory buffer which xen
writes into, and the user app reads out of. Memory read speeds are
currently in the Gb/s range. So to answer your question, I don't think
that this mechanism affects system performance in any significant way.
>
> How about make use of relayfs? It is some kind of standardization of
> the way in which large amounts of data are transferred from kernel
> space to user space.
>
If the data were only being transferred between the linux kernel and a
linux app, then I'd say yeah, relayfs sounds like a cool thing to do.
However, the trace records are generated by the xen hypervisor, not the
linux kernel. The hypervisor doesn't have relayfs (or any fs for that
matter), so you're stuck with involving the linux kernel which would
read stuff from a shared hypervisor buffer, then present the data to
userland via relayfs. Doesn't sound like a better solution than what we
have now.
Rob
next prev parent reply other threads:[~2006-06-15 17:03 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 [this message]
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
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=449192E1.4080808@hp.com \
--to=rob.gardner@hp.com \
--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.