-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Karim Yaghmour <karymat_private> writes: > > Have you run something like LMBench or HBench-OS on an LTT-enabled > > kernel? I'd be very curious about the results. It seems like > > system call latency actually doesn't matter too much under normal > > workloads - after all, most interesting system calls relate to > > I/O, which is almost always slow. But if we are to get anything > > incorporated into the main kernel tree, we have to show that our > > modifications have minimal impact on system call and interrupt > > latency. > > The impact is minimal as can be. You can check the code to that > effect. That being said, I haven't run micro-benchmarks because > I usually view them with caution (a fact that some reviewers > of the Usenix paper actually agreed on). I tend to think that > micro-benchmarks reflect fringe behavior that _may_ have little > to do with reality, hence the use of macro-benchmarks. Hey, I certainly agree micro-benchmarks don't tell you what will happen under normal loads. Certainly, I've noticed that - my code blows donkeys in micro-benchmarks, but I have a hard time measuring the impact at a macro level! Having said that, I believe this is a case of "knowing your audience." Linus, Alan, and others definitely care about micro-benchmarks, and they regularly refer to the results of programs like lmbench when evaluating the impact of different changes. After all, people have gotten kudos for tweaking the entry.S assembly code by removing one or two unnecessary instructions. So, you see, if we're going to get anything included in the kernel, it is going to have to be extremely minimal in the generic case - otherwise, it will not get included. You believe that, based on your macro-benchmarks, that the performance of the LTT is good enough. All I'm saying is that I'm not so sure that it will be so at the micro-level. The LTT may be the most efficient way to implement the functionality it does; that isn't enough to convince non-security people, though, that its overhead is worth it. In the next day or so I'll try posting a message explaining what I'd need from a security-module interface to implement my code as a module; my description may not be a good place to start on a general design, though, because it may be _impossible_ to design an interface that is flexible enough to do what I need it to do, and efficient enough to be included in the mainline kernel. What we need is an interface that can accomodate POSIX, and hopefully a few other models such as SubDomain that the general community might care about. In the end, I doubt the interface we come up with will be sufficient to implement more research-oriented projects - for those, something like the Linux Trace Toolkit may be the right starting point. --Anil - -- Anil Somayaji (somaat_private) http://www.cs.unm.edu/~soma +1 505 872 3150 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) iEYEARECAAYFAjragzsACgkQXOpXEmNZ3SeNnACfRED1hO1H1JBCJzlcPAphvy8I JQAAn2uoYhcDT7bQVdGt62JMY0944Iol =Ry2v -----END PGP SIGNATURE----- _______________________________________________ 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 : Sun Apr 15 2001 - 22:32:03 PDT