site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com Hey, Godfrey, On Dec 3, 2009, at 06:59 , Godfrey van der Linden wrote: HTH Justin -- Justin C. Walker, Curmudgeon-At-Large Director Institute for the Enhancement of the Director's Income -------- "Weaseling out of things is what separates us from the animals. Well, except the weasel." - Homer J Simpson -------- _______________________________________________ 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... For my Ph.D. research I wish to collect I/O statistics and then to attribute them to the initiating process. Ignoring the deep philosophical issues associated with this goal (that's for your thesis :-}) 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). It's been a while since I have looked at the code, but AIR, except at the very bottom or top of the stack, mbuf users tend to rely on m_data to find out where to put their data. If that be the case, then (since you're at the very bottom [I assume]), you can just "steal" the space you need by fiddling with that value. You would need a marker to tell you when one of "your" mbufs passes by, but there may be flag space available. You'd need to spend some time tracing the use of that value in kernel, NKEs, and drivers to be sure no one is "backing up" the m_data pointer. Modifying the mbuf structure can be tricky, especially in a world of plugins (and don't forget the possibility of the odd skanky user-mode process that wants to paw through the entrails of the kernel, looking for juicy bits of data). Others on the list may have more current understanding of the state of things. This email sent to site_archiver@lists.apple.com