Crispin Cowan wrote: >I remember that discussion too. While I confess that I don't remember >convincing you that /proc was too slow, I do remember a convincing proof that >it's slower than a system call: trivially, all accesses to /proc involve a >system call, and therefore the cost is syscall + /proc overhead. > >The question is "how MUCH slower" is the /proc approach than a native >syscall. Yup. As far as I can see from looking at the code, the dominant cost of either approach is the context switch. The extra overhead of /proc is basically a few pointer traversals to do the de-multiplexing, and a call through a function call. I would expect those to be negligible compared to the context switch. If there's any noticeable difference, it's more likely to be that you need to first open() the /proc file. However, this only needs to be done once, and can be amortized across many calls, so I would not expect this to have much effect, either, once all is said and done. As you say, it needs to be measured. However, unless I missed something above, my view is that, in absence of measurements or other evidence to the contrary, we should proceed on the assumption that we can make the performance of a /proc-based solution good enough, if we want to do so. _______________________________________________ linux-security-module mailing list linux-security-moduleat_private http://mail.wirex.com/mailman/listinfo/linux-security-module
This archive was generated by hypermail 2b30 : Thu Aug 09 2001 - 17:07:36 PDT