site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com Okay, I'll use that then. No. hw.ncpu = 1 hw.availcpu = 1 hw.ncpu: 1 hw.activecpu: 1 hw.logicalcpu_max: 1 hw.logicalcpu: 1 hw.physicalcpu_max: 1 hw.physicalcpu: 1 This can all change in the future, but currently: -- Terry _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... On Jun 27, 2007, at 12:01 PM, Steve Checkoway wrote: On Jun 25, 2007, at 4:50 PM, Terry Lambert wrote: activecpu is the correct name; the manifest constant name was not changed because people have existing code that has to compile vs. the MIB version of the call. The preferred method for all sysctls going forward is to use sysctlbyname(), so that's what you should use in new code. I did wonder about that. All of the examples I've seen on this list have been of the sysctlbyname() type. Is there a list of the sysctls that are guaranteed to exist on all machines (or by architecture). Also, a description of them would be nice. For example, on this computer sysctl -a|grep cpu gives me (among others): It isn't clear to me how ncpu and activecpu relate to the others. My guess is that ncpu is the same as logicalcpu_max and activecpu is the same as logicalcpu. I'm not at my G5 so I can't check my assumptions at the moment. The comments in the header do not mention physical/logical for either ncpu or activecpu. hw.ncpu is a wart; consider it to be deprecated. hw.physicalcpu is the number of physical CPUs hw.logicalcpu is the number of logical CPUs; this is for SMT, which we don't support (maybe T1s?) hw.availcpu are the number logical CPUs currently online These interfaces are evolving, however, you are unlikely to get a description of these. They are intended for internal ibrary use, and not for use by applications, since applications should use the library abstractions rather than trying to use this information directly themselves. Specifically, this information is not terrifically useful unless you know exactly how the scheduler works, and this can change from release to release, and even as a result of a software update. As a result, the only way you can safely use the information for anything is to have your code sent out in lockstep with software updates. This happens for system libraries, when something that matters to the library changes, but rarely happens anywhere else. This email sent to site_archiver@lists.apple.com