October 2006 - Darwin-kernel

Re: thread_t, uthread_t, at al.?
by plumber Idraulico 28 Oct '06

28 Oct '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Hi, all thus my intuition was good , a wrong way/approach I'm less and less impressed with the overall design of Unix/Darwin APIs and code I'm more and more impressed, except about some little points ... but it's not the question here XNU opened a way in the Kernel design if you are interested by Kernel design learn other kernels ... and you 'll can compare : Hi Mike Windows Kernel too :D ... you can share your point of view but you cannot to say : "XNU is bad" ! XNU is not perfect but XNU is really good Peace -plum _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… in first : I thought that you wanted to implement a code concerning another kernel "this approach exists on other nix*ss" I'm walking the VFS data structures looking for the processes that have files open. for my opinion an other interesting view about "NEw" kernel design is DragonFlyBSD and the LWKT model There is more than thirty years times thousands of engineers worth of design and experience embodied in the Darwin kernel, and to say that you're "not impressed" because you don't understand it and/or it doesn't satisfy your presumptions ... it's like saying you're not impressed by the Hoover Dam because it's "just concrete". 8) This email sent to site_archiver(a)lists.apple.com

1 0

Re: thread_t, uthread_t, at al.?
by Michael Smith 28 Oct '06

28 Oct '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Successive approximation is a remarkable tool. = Mike _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… On Oct 27, 2006, at 12:42 PM, Rick Mann wrote: So far though, I can't think of anything that involves tracking the process to which a thread belongs in what I've outlined above. You aren't making an assumption about v_owner, are you? Looking at the sources, v_owner is either null or it's current_thread(), but I guess that can change as a file is accessed, so that won't be reliable at all. Modulo bugs in the code, it is completely reliable. It's just not what you thought it was. I mean, it's not reliable as an indicator of which process is keeping a volume busy, my end goal. I think Terry's done a pretty good job of elaborating what you'd need to do in order to achieve your end goal. As for speculation; Terry is one of the folks that maintains the code and datastructures in question here. Happy now? 8) The Darwin kernel lacks dozens of APIs that would allow safe inspection of system state by forcing me to inspect the data structures directly. I'm not quite sure what that sentence was intended to mean. Another way to think about it is that the Darwin kernel design avoids making guarantees or creating/maintaining data that are not relevant to the tasks it is attempting to accomplish. Offering thousands of APIs (dozens for your specific application multiplied by hundreds of similar, specific applications) would greatly hinder any sort of development of the system. Apple decided, instead of freezing their API set and stifling innovation both internally and externally, to restrict what is guaranteed and then provide a way for third parties to enhance beyond what they can do with the APIs at the cost of some development overhead and lock-step release cycles. It's not perfect, but the alternative (stagnation) would quickly become much worse. What you are looking for is a small facet of a very large and complex problem (general service accounting). A decent solution to the problem would require a great deal of work with little or no regular practical application. Instead, you are tasked with a narrow solution that solves your particular problem. In the few hours I spent looking at the source over the last day, I've found a great deal of sloppiness, due mainly to the fact that this code has evolved over decades and has been altered by hundreds of people, people who didn't all share the same vision of what the code base was or should be. I'd be willing to experiment with adding support to the Kernel & BSD to keeping track of these things as files are opened and closed (as I said above, I don't agree with your assertion that this needs to have any significant impact on performance). Any kind of work impacts performance; my point was simply that as a matter of principle the Darwin code avoids doing unnecessary work. Sure, you can argue that making every codepath that adds or removes a reference to a vnode take another 50µs doesn't look like a "significant" impact, but if you keep thinking that way you quickly end up with a pig. You might also count the number of cycles spent tracking that information when the information is not actually used. The ratio of useful vs. not-useful work would be billions to one, at least. I was hoping to find support here, and I've found some. Mostly enough to keep me from pursuing a dead-end. But I've also met with a certain degree of resistance and arrogance. Well, to be honest, you've brought your fair share as well. You're getting answers from people that live this code on a daily basis; do you expect them to react well when you rank your "speculation" over their experience? Especially when you're essentially complaining that despite everything else they are committed to do, you think that something that serves your personal ends is more important? This email sent to site_archiver(a)lists.apple.com

1 0

Re: seeking overview of scheduling on dual-core (or more)
by Sean W. Smith 28 Oct '06

28 Oct '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Thanks, Sean PS: Which team member? _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… I did look through that quickly (mainly in the index, for things like "multiprocessing"). But I'll take another look. This email sent to site_archiver(a)lists.apple.com

1 0

Re: thread_t, uthread_t, at al.?
by Terry Lambert 27 Oct '06

27 Oct '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com The what things are stores is that there is a list of processes. For each of these processes, there is a per process open file table. So don't do that - pretty simple. - (3) You only push useful data, instead of pushing everything -- Terry _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… On Oct 27, 2006, at 12:42 PM, Rick Mann wrote: On Oct 27, 2006, at 12:21 , Michael Smith wrote: There is a reason that lsof does this. The information you're looking for is not maintained by the system; it would be expensive to do so, and the work would almost always be wasted. I'm not sure I agree with this assertion. I don't think it would be asking too much. The Mac OS (Carbon) file system was able to do it, and I hardly think that support could be blamed for any significant slowdown. (Mind you, this is speculation). Carbon did this in pre-Mac OS X days by running in the same address space; if you don't do protection domain crossing for each piece of information, it's a heck of a lot easier to do what you are trying to do. If you have to cross protection domains (e.g. because you have an OS that prevents one application from brining unrelated applications down (best case) or the whole system down (worst case), then it's very expensive. For each per process open file table entry, there's a pointer to a fileglob. Multiple open file instances in the same process and in other processes in the system (either child, parent, or processes which have used UNIX domain sockets to pass an open descriptor around) can point to the same fileglob. For a fileglob, there's a pointer to an fd_data; what this represents depends on the type of entry that it represents (e.g. vnode, pipe, socket, etc.). Multiple file globs can point to the same thing (in this case, you are caring about vnodes). The vnode points to the v_data, which represents the in core data necessary to access a vnode object - usually, a filesystem object ; there is *usually* a 1:1 correspondence between vnode and per-FS instance object; in the case of HFS, this would be a cnode structure, or for UFS, an inode structure. So basically, you have two places in the chain you want to back-track where the OS doesn't store a list of "who all points to me?". You're correct that this *could* be maintained by the OS, but you're *wrong* when you say "I hardly think that support could be blamed for any significant slowdown". The problem is that in order to maintain these lists, you would need to allocate list element structures in both cases (this is doable - it's just a memory penalty); however, when you went to insert and remove elements from these lists, you'd have to enforce a serialization barrier on list insertion, deletion, lookup, uniquification, etc., etc.. Pre-protected-mode Mac OS X would handle this by duplication of data and/or hlock()/hunlock() - serializing either data validity or serializing access. This isn't really expensive on a non-preemptive multitasking system where you don't have protection domain crossing or address space switching, and for which you only have a single CPU that you're stalling out until the operation completes. But when you start talking about modern machines and modern OS's that are inherently more safe vs. viruses, etc., then you are starting to add up to some real performance penalties. So far though, I can't think of anything that involves tracking the process to which a thread belongs in what I've outlined above. You aren't making an assumption about v_owner, are you? Looking at the sources, v_owner is either null or it's current_thread(), but I guess that can change as a file is accessed, so that won't be reliable at all. Modulo bugs in the code, it is completely reliable. It's just not what you thought it was. I mean, it's not reliable as an indicator of which process is keeping a volume busy, my end goal. If this is your goal, you need to reconsider the information you think you need in order to accomplish it. In this case, you have a volume that's being held open by (presumably) a small number of vnode references, and you want to know where they are coming from. You can do this the slow way, which is to walk everything, or you can do this the fast way. The primary reason lspf is slow in this case is that it displays all the information, and in obtaining this information, it bushes all the data, as individual data items, across the user/kernel protection domain boundary. So you are basically spending all your time in TLB shootdown, flushing, address space crossing, and copying data that not interesting for the problem you are trying to solve. What you likely want to do is make yourself a KEXT that needs to be recompiled vs. each instance of the kernel, so that if anything changes, the promiscuous knowledge you are using to walk the data structures (i.e. "the data structure has such-and-such a layout", "the pointer to such and such a list starts here", "this list is a STAILQ vs. a TAILQ or an SLIST", etc., etc. -- all the implementation we won't promise won't change between software updates) is valid for the kernel you load the thing into. Then you ask your KEXT to send you only the information you want: you iterate the vnode list off the mount point using the locking-of-the- day that happens to be implemented in a particular version of the OS, and get together a list of vp's keeping the volume open. The next part, you are going to want to take in two passes; the first is mandatory, the second, optional: First pass, you iterate the proclist, and iterate the open file table for each proc, and look in the fg_data pointer for the vp's you are interested in. You copy this out all at once. Second pass (if the first pass turns nothing up, or you are being pedantic, even though you know you can't close the volume with the vnodes held by the first pass), you go through the vnode object mappings for all the processes, and look to see if one of the vm objects associated with the process is associated with the vnode pager, and if so, if the backing object for the pager happens to be one of the vnodes you are interested in. The benefits to doing it this way should be obvious from the above, but I'll spell them out: (1) The information from lsof is a snapshot; going at it this way, you can get real data; byt the time you display it, it'll also be a snapshot, but it will be a *consistent* snapshot (2) The information doesn't have to have multiple boundary transitions to get one piece of data (I think lsof is up in the neighborhood of 7 boundary crossing per vnode backed file to display anything, not including the display code) (4) You are order N*M/2, rather than order N * M * K, where K is large, because you iterate only for the vnodes you care about, instead of all of them. (5) You avoid all that copying of data, TLB mapping, shodown, buffer flushing, etc.. The down side is that you have to recompile your KEXT each time an sU happens, but if you are traking a bug in FS code you wrote yourself, this should be no big deal. All I want to so is add some very useful functionality that existed in the pre-Mac OS X Mac: the ability to tell who's got a volume open when you try to unmount it via the Finder. I can't actually fix the Finder, but I can come close with a contextual menu plugin. The only mechanism to determine this is lsof, which is slow and unreliable (it does not detect files opened by the Kernel). I was hoping to find another way. Actually, no. If you wanted to do this, you could simply write an fsevents listener, and remember who did what open, keeping a count on the open and closes, removing records in your list when the open cout for a given process goes to 0. If you wanted to do this via a KEXT, and query it for the information, that's really easy, too, by using a KAUTH listener for open and close events. I'd be willing to experiment with adding support to the Kernel & BSD to keeping track of these things as files are opened and closed (as I said above, I don't agree with your assertion that this needs to have any significant impact on performance). If you want to do this for your own use, that's fine, but the performance penalties on a heavily loaded system could be immense (see above). This email sent to site_archiver(a)lists.apple.com

1 0

Re: seeking overview of scheduling on dual-core (or more)
by Terry Lambert 27 Oct '06

27 Oct '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On Oct 27, 2006, at 3:44 AM, Sean W. Smith wrote: Howdy! Have you looked at: Mac OS X Internals: A Systems Approach Amit Singh Addison-Wesley ISBN 0-321-27584-2 Chaptet 7: Processes Section 7.4 Scheduling ? -- Terry _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… I'm teaching an OS course. Now that Mac Minis are coming with dual-core Intel CPUs by default, some students are asking how OSX handles scheduling for multi-CPU platforms. Poking around, I wasn't able to find an answer. Can anyone point me in the right direction? Hi! One of our kernel team managers was a CS professor at Dartmouth, where you're posting from... This email sent to site_archiver(a)lists.apple.com

1 0

Re: Upgrading a ROM based KEXT
by Dean Reece 27 Oct '06

27 Oct '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Cheers, - Dean _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… On Oct 27, 2006, at 12:27 PM, Michael Smith wrote: On Oct 27, 2006, at 11:20 AM, Satyam Lad wrote: The probe score will always be the same as the info.plist is the same for both the KEXT's. The only difference in both the KEXT (in terms of info.plist) is of "CFBundleVersion" property. The new KEXT has a higher number then the older (ROM) KEXT. This won't achieve your desired goal; version numbers are not considered when matching, only the probe score counts. If you want the kext to win vs. the ROM, you need to ensure the kext has a higher probe score. Actually, that true only if the two kexts have different CFBundleIdentifiers. The way it is *supposed* to work in this case is as Satyam is attempting The kext managmenet system will collect all the versions it can find for any given CFBundleIdentifier and attempt to use the latest version. The fact that it is working as expected on the first reboot tells me that he has it mostly working correctly. The fact the subsequent reboots use the ROM kext indicates that perhaps his newer kext isn't getting included in the kext cache. What happens if you safe boot (hold the shift key down), which bypasses the caches and goes back to scanning for individual kexts. Does it get the newer kext then? This email sent to site_archiver(a)lists.apple.com

1 0

Re: thread_t, uthread_t, at al.?
by Rick Mann 27 Oct '06

27 Oct '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On Oct 27, 2006, at 12:21 , Michael Smith wrote: I have it. It's what led me to try this approach. -- Rick _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… There is a reason that lsof does this. The information you're looking for is not maintained by the system; it would be expensive to do so, and the work would almost always be wasted. I'm not sure I agree with this assertion. I don't think it would be asking too much. The Mac OS (Carbon) file system was able to do it, and I hardly think that support could be blamed for any significant slowdown. (Mind you, this is speculation). So far though, I can't think of anything that involves tracking the process to which a thread belongs in what I've outlined above. You aren't making an assumption about v_owner, are you? Looking at the sources, v_owner is either null or it's current_thread(), but I guess that can change as a file is accessed, so that won't be reliable at all. Modulo bugs in the code, it is completely reliable. It's just not what you thought it was. I mean, it's not reliable as an indicator of which process is keeping a volume busy, my end goal. Coming from over a decade of Mac OS development, I'm less and less impressed with the overall design of Unix/Darwin APIs and code. This is very frustrating. I understand your frustration, especially given the clean break between the legacy Mac OS and Darwin, but I don't think that being insulting about it is going to help anything. There is more than thirty years times thousands of engineers worth of design and experience embodied in the Darwin kernel, and to say that you're "not impressed" because you don't understand it and/or it doesn't satisfy your I don't think 30 years and thousands of engineers necessarily leads to better code. In fact, I think most of the time it leads to poorer code. The Darwin kernel lacks dozens of APIs that would allow safe inspection of system state by forcing me to inspect the data structures directly. In the few hours I spent looking at the source over the last day, I've found a great deal of sloppiness, due mainly to the fact that this code has evolved over decades and has been altered by hundreds of people, people who didn't all share the same vision of what the code base was or should be. If you haven't already, I recommend you grab a copy of Amit Singh's book. It's very good. All I want to so is add some very useful functionality that existed in the pre-Mac OS X Mac: the ability to tell who's got a volume open when you try to unmount it via the Finder. I can't actually fix the Finder, but I can come close with a contextual menu plugin. The only mechanism to determine this is lsof, which is slow and unreliable (it does not detect files opened by the Kernel). I was hoping to find another way. I'd be willing to experiment with adding support to the Kernel & BSD to keeping track of these things as files are opened and closed (as I said above, I don't agree with your assertion that this needs to have any significant impact on performance). However, I'm finding it ridiculously difficult to actually build from Apple-provided sources, and as far as I can tell, OS X 10.4.8 Intel sources aren't even available. I was hoping to find support here, and I've found some. Mostly enough to keep me from pursuing a dead-end. But I've also met with a certain degree of resistance and arrogance. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Upgrading a ROM based KEXT
by Michael Smith 27 Oct '06

27 Oct '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On Oct 27, 2006, at 11:20 AM, Satyam Lad wrote: = Mike _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… The probe score will always be the same as the info.plist is the same for both the KEXT's. The only difference in both the KEXT (in terms of info.plist) is of "CFBundleVersion" property. The new KEXT has a higher number then the older (ROM) KEXT. This won't achieve your desired goal; version numbers are not considered when matching, only the probe score counts. If you want the kext to win vs. the ROM, you need to ensure the kext has a higher probe score. This email sent to site_archiver(a)lists.apple.com

1 0

Re: thread_t, uthread_t, at al.?
by Michael Smith 27 Oct '06

27 Oct '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On Oct 27, 2006, at 10:52 , Michael Smith wrote: "ownership" is a poor way of thinking about the concept. = Mike _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… On Oct 27, 2006, at 11:05 AM, Rick Mann wrote: That's doing it the hard way, as there is a one-to-many relationship between vnodes and file descriptors and as I recall no straightforward way to go from the former to the latter. Hmm. I guess you're telling me that a process would own a file descriptor, but but not a vnode. Crap, this throws a wrench in my works. The vnode represents the "file"; it is global in scope, and has global context that must be consistent regardless of who is looking at it. A file descriptor is process-wide in scope; it has context that must be consistent across any thread in the process, but should not be affected by any other process. The internal implementation of the file descriptor is actually more complex than this; they are intentionally broken into several parts to accomplish a number of additional objectives, but since you want to associate open files with processes, you need to consider the 1:1 view of the relationship, not the 1:m side. Really, you want to take this on from the consumer side, not the provider side. Walk the descriptor table for each process to enumerate files that are held open with a descriptor. Then walk the memory map for each process, tracking down the mapped VM objects and following them back to their respective pagers to work out whether they are backed by a file that is not otherwise open. I believe this is what lsof does, and it's very slow. There is a reason that lsof does this. The information you're looking for is not maintained by the system; it would be expensive to do so, and the work would almost always be wasted. So far though, I can't think of anything that involves tracking the process to which a thread belongs in what I've outlined above. You aren't making an assumption about v_owner, are you? Looking at the sources, v_owner is either null or it's current_thread(), but I guess that can change as a file is accessed, so that won't be reliable at all. Modulo bugs in the code, it is completely reliable. It's just not what you thought it was. Coming from over a decade of Mac OS development, I'm less and less impressed with the overall design of Unix/Darwin APIs and code. This is very frustrating. I understand your frustration, especially given the clean break between the legacy Mac OS and Darwin, but I don't think that being insulting about it is going to help anything. There is more than thirty years times thousands of engineers worth of design and experience embodied in the Darwin kernel, and to say that you're "not impressed" because you don't understand it and/or it doesn't satisfy your presumptions ... it's like saying you're not impressed by the Hoover Dam because it's "just concrete". 8) If you haven't already, I recommend you grab a copy of Amit Singh's book. It's very good. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Re: thread_t, uthread_t, at al.?
by Shawn Erickson 27 Oct '06

27 Oct '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Mq7xH3WtQWsY+bN4Xg8bjyJf8/aXsZ+rmjVOUVyzw4wdnqQRHgx/7wXQaled3CHuGCzp04+qbnuEmEcVqKPgYNX/URIFsUe//YNbseqmCOYSpx1//RXSkIClixgavh0J0A7pAS1Hl3kj8BN7TGtDxAVyLHWDfFpKnOYPZHs0Tu0= On 10/27/06, Rick Mann <rmann(a)latencyzero.com> wrote: Coming from over a decade of Mac OS development, I'm less and less impressed with the overall design of Unix/Darwin APIs and code. This is very frustrating. The computing model of Darwin (and Unix) is far richer then what we had in Mac OS, as a result assumption that held true in Mac OS do not hold true in Mac OS X. -Shawn _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0