site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com Start by looking at soreceive. And after you've finished cursing at people that think that "refactoring" is something that you do with fractions, you're looking for uiomove calls, not copyout. = Mike On Dec 4, 2009, at 12:54 PM, Godfrey van der Linden wrote:
Hey guys. I think my idea can work and it will be pretty narrow changes. I'll explore the tagging infrastructure to move some data around.
The ifconfigd/xinted target process doesn't worry me too much, firstly my project is to build developer tools and some developer support will be required, but secondly I don't mind if I mis-attribute a few I/Os as long as I get the primary data paths covered. This simplifies my problem so that shared resource isn't a big problem either.
I think the place I'm after is where the mbuf does a copyout into the user process. I had hoped that mbuf_copyout would be in kpi_mbuf.c but it doesn't seem to be the case. So a quick question, where does this occur, is it spread out over many different stacks or is there a centralised mbuf copyout somewhere burred in the net stacks. Cscope reports that copyout is called from way to many places in the whole network infrastructure for a newbie like me to understand.
Cheers
Godfrey
On 2009-12-04, at 3:44 AM, Josh Graessley wrote:
It may be possible to use mbuf tags. Mbuf tags allow you to attach additional information to an mbuf. The downside is that mbuf tags are not as light weight as they ought to be. Internally the stack allocates another mbuf for the tag.
I think you'll need to go in to each protocol at the socket layer and modify the code to add the tag. That may also require modifying the socket to track the current owning process. Some sockets are shared across processes. The most common example are sockets created in launchd for incoming connections and then handed off to another process to handle the socket. If I remember correctly, the new connection is created in the kernels context and placed on the listening queue. The listening socket is shared with another process which is responsible for calling accept. The process of calling accept probably creates the new socket.
One other example if sharing sockets is a helper utility that runs as root to create a socket and bind it to a low numbered port and then hand it off to another process. The stack doesn't currently track the notion of the owning process for a given socket so handling this could be tricky.
Sent from my iPhone
On Dec 3, 2009, at 6:59, Godfrey van der Linden <gvdl@mac.com> wrote:
G'day, Kernel dudes.
For my Ph.D. research I wish to collect I/O statistics and then to attribute them to the initiating process.
I'm going to be building a new kernel that can track per-process I/O stats. This is reasonably easy to do for raw IOKit memory descriptor I/Os, I can tag the descriptor with a process tag and on completion accumulate it into data. This should be a reasonably narrow change primarily to IOKit.
However, the network stats presents a problem, the drivers where I collect the data do not know which process attribute them to until the top of the network stack. I've had an idea that may work but I'd like real networking experts opinion.
A natural analog to memory descriptors in networking is the mbuf structure. I'd like to add a new field for my research kernel that points to the data collected by the driver. Then I'll modify the top of the networking stack to accumulate it into per process data.
Is this the easiest way of doing this or is their an easier way? Your opinions and advice will be gratefully received. Note the code is very carefully written to be extremely light weight and lock-free (in the sense that no additional locks are required over and above the locks already used by networking. There will be some cache invalidation which appears to be unavoidable).
Cheers
Godfrey
_______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/jgraessley%40apple.com
This email sent to jgraessley@apple.com
_______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/drivers%40mu.org
This email sent to drivers@mu.org
_______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... This email sent to site_archiver@lists.apple.com