March 2004 - Darwin-kernel - lists.apple.com

Re: Getting system performance
by Godfrey van der Linden 31 Mar '04

31 Mar '04

No it wont. I thought you were interested in the kernel as you sent your request to the darwin-kernel mailing list. Try 'man 3 time' Godfrey On 2004 Mar 31, at 12:03, Lamont Cranston wrote: > >Are you in IOKit space? > > What I'm trying to do is write a command line tool that measures AIO > disk performance. > So using routines in the Kernel framework isn't going to work, is it? > > > > Do you Yahoo!? > Yahoo! Finance Tax Center - File online. File on time. _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.

1 0

Re: Getting system performance
by Lamont Cranston 31 Mar '04

31 Mar '04

>Are you in IOKit space? What I'm trying to do is write a command line tool that measures AIO disk performance. So using routines in the Kernel framework isn't going to work, is it? Yahoo! Finance Tax Center - File online. File on time. _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.

1 0

Re: Getting system performance
by Godfrey van der Linden 31 Mar '04

31 Mar '04

#include <kern/clock.h> clock_get_uptime is in CPU cycles. clock_get_system_nanotime() is in nanoseconds. Just check the header out there is a whole lot of APIs in there for. You can get access to the counters using the CHUD framework, check out the developer's website for details. Are you in IOKit space? Godfrey On 2004 Mar 31, at 7:27, Lamont Cranston wrote: Is there any way to get a high resolution system uptime in nanoseconds or in number of CPU cycles? Also, I am interested in gathering CPU utilization statistics and number of interrupts during I/O. Is there any method of doing this? Can the PMC registers be used? If so, is there any documentation on how to program the MMCR registers? Should one use the processor_control() method (mach/processor.h, mach/ppc/processor_info.h) to do this? _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.

1 0

Getting system performance
by Lamont Cranston 31 Mar '04

31 Mar '04

Is there any way to get a high resolution system uptime in nanoseconds or in number of CPU cycles? Also, I am interested in gathering CPU utilization statistics and number of interrupts during I/O. Is there any method of doing this? Can the PMC registers be used? If so, is there any documentation on how to program the MMCR registers? Should one use the processor_control() method (mach/processor.h, mach/ppc/processor_info.h) to do this? Thanks Yahoo! Finance Tax Center - File online. File on time. _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.

1 0

Re: Proper termination of an IOKit driver
by Godfrey van der Linden 31 Mar '04

31 Mar '04

G'day Brad, I'm going to make a couple of assumptions. One that you have a user client and the user client has your driver IOService::open()ed. This is by far the easiest way of controlling this. Let the user client control your driver and refuse to close() it until after all oustanding I/Os are completed. If you are going to be particularly clean you can also override your drivers IOService::terminate() function. I'd recommend that your driver would return all outstanding I/Os with a kIOReturnOffline error. Your user client should be reference counting outstanding requests and should close its provider as soon as possible after it receives the didTerminate() message. Tear down is very tricky to get right as some very complicated locking occurs. In general there is no reliable way to guarantee a safe tear down unless you synchronise with your providers workLoop, though of course this assumes that your driver is workLoop aware. (This is still soluble but you need to use slightly different, more complicated techiques). Hope this helps. Godfrey van der Linden PS. I briefly covered device driver teardown during my WWDC presentation last year. Do you have access to the DVDs? On 2004 Mar 30, at 10:10, Brad Post (MACBU) wrote: I am having problems with the unloading of an IOKit Driver and I need some guidance as to the correct method to solve it. The driver is based off the same code, so we only have the standard functions: init, free, probe, start & stop The problem we're running into is that the user can call kextunload on our IOKit, which calls the stop method. Our code recognizes that the application is still using the driver and fails, and we never call the super::stop method. Unfortunately the IOServices removes our driver from the IORegistry, and when the user then tries to reload the driver with kextload bad things go amuck.... Forget the fact that this is an edge-case senario, and I know the minute the user starts using kextunload, we don't really have to play nice, but I want to play nice. We don't unload, which I thought was enough, but now I have to figure out how to stop IOServices from removing us from the IORegistry. Is there a routine I need to be calling or some message I need to be listening for? Sample code? Thanks. Brad =3D=3D=3D=3D< my code snippet >=3D=3D=3D=3D=3D void mykextclass::stop(IOService *provider) { kern_return_t result =3D KERN_SUCCESS; IOLog("Stopping\n"); result =3D mydriver(provider); if (result =3D=3D KERN_SUCCESS) super::stop(provider); } _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored. _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.

1 0

Re: Proper termination of an IOKit driver
by Fernando Urbina 30 Mar '04

30 Mar '04

On 3/30/04 12:46 PM, "Dean Reece" <dean.reece(a)apple.com> wrote: > I'm not aware of a particularly relevant example, but look around in > Darwin for drivers that implement terminate(). > You could look at the IOUSBFamily project in Darwin and look at one of our drivers, such as the IOUSBHIDDriver. We implement I/O reference counting so that we are not terminated while we have pending I/O. We use willTerminate() and didTerminate() and the open/close semantics (on our provider). -- Fernando Urbina mailto:nano@apple.com USB Technology Team work: 719.534.9387 Apple Computer, Inc. fax: 719.532.0981 _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.

1 0

Re: Proper termination of an IOKit driver
by Dean Reece 30 Mar '04

30 Mar '04

Hi Brad, On Mar 30, 2004, at 10:10 AM, Brad Post (MACBU) wrote: I am having problems with the unloading of an IOKit Driver and I need some guidance as to the correct method to solve it. The driver is based off the same code, so we only have the standard functions: init, free, probe, start & stop The problem we're running into is that the user can call kextunload on our IOKit, which calls the stop method. Our code recognizes that the application is still using the driver and fails, and we never call the super::stop method. Unfortunately the IOServices removes our driver from the IORegistry, and when the user then tries to reload the driver with kextload bad things go amuck.... The problem is that you are trying to prevent the termination of your driver too late in the chain of events. By the time stop() has been called, the system has decided your driver object is no longer needed. Also, failing to call super::stop() introduces other problems, as you discovered. I'm curious, did you see this done somewhere else or find some documentation that indicated not calling super::stop() was appropriate? What you need to do is override terminate() and return false in cases where you don't want the termination process to proceed. >From IOService.h, discussion of terminate(): Registering an IOService informs possible clients of its existance and instantiates drivers that may be used with it; terminate involves the opposite process of informing clients that an IOService is no longer able to be used and will be destroyed. By default, if any client has the service open, terminate fails. If the kIOServiceRequired flag is passed however, terminate will be sucessful though further progress in the destruction of the IOService will not proceed until the last client has closed it. The service will be made inactive immediately upon successful termination, and all its clients will be notified via their message method with a message of type kIOMessageServiceIsTerminated. Both these actions take place on the callers thread. After the IOService is made inactive, further matching or attach calls will fail on it. Each client has its stop method called upon their close of an inactive IOService, or on its termination if they do not have it open. After stop, detach is called in each client. When all clients have been detached, the finalize method is called in the inactive service. The terminate process is inherently asynchronous since it will be deferred until all clients have chosen to close. Additionally, something should be calling open() on your driver while your app is using it, and close() once it is done. Generally, this would be done by your IOUserClient, but the driver could call open()/close() on itself if it is serving as it's own conduit to user-space. Forget the fact that this is an edge-case senario, and I know the minute the user starts using kextunload, we don't really have to play nice, but I want to play nice. We don't unload, which I thought was enough, but now I have to figure out how to stop IOServices from removing us from the IORegistry. It is reasonable to prevent unloading while it is in active use - that is just good defensive programming. The problem you are having is that failing to call super::stop() isn't the right approach (and in fact causes other problems). Is there a routine I need to be calling or some message I need to be listening for? terminate(), open(), and close() are where you should be looking. Sample code? I'm not aware of a particularly relevant example, but look around in Darwin for drivers that implement terminate(). Cheers, - Dean Thanks. Brad =3D=3D=3D=3D< my code snippet >=3D=3D=3D=3D=3D void mykextclass::stop(IOService *provider) { kern_return_t result =3D KERN_SUCCESS; IOLog("Stopping\n"); result =3D mydriver(provider); if (result =3D=3D KERN_SUCCESS) super::stop(provider); } _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.

1 0

Proper termination of an IOKit driver
by Brad Post (MACBU) 30 Mar '04

30 Mar '04

I am having problems with the unloading of an IOKit Driver and I need some guidance as to the correct method to solve it. The driver is based off the same code, so we only have the standard functions: init, free, probe, start & stop The problem we're running into is that the user can call kextunload on our IOKit, which calls the stop method. Our code recognizes that the application is still using the driver and fails, and we never call the super::stop method. Unfortunately the IOServices removes our driver from the IORegistry, and when the user then tries to reload the driver with kextload bad things go amuck.... Forget the fact that this is an edge-case senario, and I know the minute the user starts using kextunload, we don't really have to play nice, but I want to play nice. We don't unload, which I thought was enough, but now I have to figure out how to stop IOServices from removing us from the IORegistry. Is there a routine I need to be calling or some message I need to be listening for? Sample code? Thanks. Brad =3D=3D=3D=3D< my code snippet >=3D=3D=3D=3D=3D void mykextclass::stop(IOService *provider) { kern_return_t result =3D KERN_SUCCESS; IOLog("Stopping\n"); result =3D mydriver(provider); if (result =3D=3D KERN_SUCCESS) super::stop(provider); } _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.

1 0

Re: Using Altivec for TCP checksum calculations
by Justin Walker 27 Mar '04

27 Mar '04

On Mar 26, 2004, at 10:09, Brian Tabone wrote: I was reading up on the PowerPC 7455, and happened upon an interesting document (http://e-www.motorola.com/files/if/cnb/ALTIVECTCPIPWP.pdf) on Motorola's website. This document covered the advantages of doing TCP checksum calculations in the Altivec SIMD unit versus doing it in the scalar integer units. Digging around in the xnu source, I found the checksum assembly code for Darwin (in bsd/dev/ppc/xsumas.s) and found that it was doing the checksum calculations in the integer units. My question is , beyond having to support the G3, is there any reason why the Darwin kernel does the checksum calculations in scalar code versus doing it in vector code? Is there reason to avoid Altivec instructions in the kernel? We looked at this when the G4 first showed up. As I recall, the consensus among those involved was that the setup time, together with alignment requirements, coupled with the problems associated with dealing with Altivec in the kernel, made this a non-starter. I suppose it's always worth revisiting, but for Altivec to be valuable, you have to have a fair amount of data, properly set up, to use this. Given the normal size of TCP data, this is a stretch. Regards, Justin -- Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics | "Weaseling out of things is what | separates us from the animals. | Well, except the weasel." | - Homer J Simpson *--------------------------------------*-------------------------------* _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.

1 0

Re: Using Altivec for TCP checksum calculations
by Joshua Graessley 26 Mar '04

26 Mar '04

On Mar 26, 2004, at 10:09 AM, Brian Tabone wrote: > I was reading up on the PowerPC 7455, and happened upon an interesting > document (http://e-www.motorola.com/files/if/cnb/ALTIVECTCPIPWP.pdf) > on Motorola's website. This document covered the advantages of doing > TCP checksum calculations in the Altivec SIMD unit versus doing it in > the scalar integer units. > > Digging around in the xnu source, I found the checksum assembly code > for Darwin (in bsd/dev/ppc/xsumas.s) and found that it was doing the > checksum calculations in the integer units. My question is , beyond > having to support the G3, is there any reason why the Darwin kernel > does the checksum calculations in scalar code versus doing it in > vector code? Is there reason to avoid Altivec instructions in the > kernel? > > I'm assuming that there should be some way to test for altivec and use > the scalar code when the altivec is not available so that the kernel > remains compatible with the G3. > > If Motorola's numbers are to be believed, it would seem that this > tweak would open up a potential bottleneck in the TCP stack, leaving > more CPU time to do stuff like serve web pages and query databases. > This would be a fine tweak for a web server or some other network busy > server type. There are two factors in involved here. If you use altivec in the kernel, you have to do some additional work to save and restore the registers. Any gains from altivec would have to be balanced against the cost of using altivec in the kernel. In addition, many NICs including those built-in to some of our machines, support hardware checksums. -josh [demime 0.98b removed an attachment of type application/pkcs7-signature which had a name of smime.p7s] _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.

1 0