site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com User-agent: Thunderbird 2.0.0.21 (Windows/20090302) Thierry -- Terry Hi all, So my questions are: Any help would be greatly appreciated ... Cheers, Thierry begin:vcard fn:Thierry Bultel n:Bultel;Thierry org:Atempo SA;V.O.S team adr;dom:;;+33297683688 email;internet:thierry.bultel@atempo.com title:Software engineer tel;work:+33297683688 note;quoted-printable:=0D=0A= =0D=0A= version:2.1 end:vcard _______________________________________________ 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... This email sent to site_archiver@lists.apple.com Terry Lambert a écrit : Number of actual open fds relative to the default administrative limit on the number of open fds is not a useful measure of overall load. Sure it is not ! Among other reasons is that we do not scale the administrative limit on the basis of hardware capability. Another is that not all types of fds consume equivalent per-fd resources, so even if the limit were scaled you couldn't trust it to be meaningful across different workload profiles.. Yes, but for the type of application I am working on, the number of fds is usually and typically the first ressource that gets exhausted (when improper setup is done by the user of application). Let's say that checking the fds usage is better than nothing, and is a first step of a more smart check. PS: Even if my questions 2) and 3) below are more general than this topic, I would really be happy to get pointers to related documentation and/or examples ... On Mar 27, 2009, at 2:22 AM, Thierry bultel <thierry.bultel@atempo.com> wrote: I would really appreciate if you could take some time to comment on the problems I have: In order to implement an early detection of the system load, before launching any job that would put the machine to its limits or worse ;-) , we would like to find out the current usage of file descriptors, in the entire system. If we could access that information, we would be able to compare it with the max limit and therefore decide if we continue or not, depending on a configurable threshold. I have done some investigations around sysctl (CTL_KERN + KERN_FILE) but it sounds like that part of the interface is not supported, because the matching structures of the returned buffer are not public. Notice that I am thinking about having a kind of heuristic that would determine the number of files, by only using the size of the 'struct extern_file', dividing, and forgetting the filehead, whose size is small comparing to the sum of the others. If I want to be more accurate than that, for simplicity of code, and also, performances concerns, I do not want to base it on lsof. (As I think that spawning executables and parsing output is generally a bas idea ...). Therefore I also have investigated on other ways how to possibly access the global kernel variable "nfiles", for example from a kext. Although It was relatively quick and easy to have a kind of "hello world" kernel extension, I have not been able to access the aimed variable. I guess it is not public or something of the same flavour. 1) What is your advice to get the current usage of file descriptors ? 2) As a general question: Is there a special way to access the kernel symbols from a kext ? How are (if any) public symbols declared in the kernel ? 3) Is it possible to declare a new syscall from a kext ? I have not found any examples on the web ...