On Thursday, August 29, 2013 02:14:32 PM zhu xiuming wrote: > Thanks a lot. > May I ask for more information? > > I am a little confused by the code. What is the reason behind that? To measure the impact, you have to repeat the test over and over. So, what you want to do is create a test that does a syscall and loops on it. You test with audit disabled and then reboot with audit enabled and run the same test. You also have to shutdown as many dameons as possible because they alter the OS timing. > It seems that the test.c only access /usr/include directory.But "access" > does not trigger any rules in auditd. Sure it does. If you have a syscall rule on open, for example, the audit system does not know if the syscall is of interest. So it walks through the list of rules to see if any match the current syscall. If it does, then it starts walking through each field of that rule. So, if you want to do a thorough study, then you want to test both misses and hits to see how much time is spent in both cases and then compare that when the audit system is not enabled and no rules loaded to when the audit daemon is enabled and rules loaded. You might also compare to when the audit daemon is enabled but there are no rules loaded. > Or you mean the test.c only stress the cpu? Nope. Any syscall affects the audit system. But you want to do micro benchmarks to see the cumulative effect. Its easier to see a 5% performance hit on a microbenchmark that runs for 30 seconds than one that takes milliseconds to complete. You can also change the syscall to see if different syscalls have more impact than others. For example, the rename syscall probably gets hit hard because it has to create auxiliary records when there is a match. You might test networking as filesystem watches, too. -Steve > On Thu, Aug 29, 2013 at 1:24 PM, Steve Grubb <sgrubb(a)redhat.com&gt; wrote: > > On Thursday, August 29, 2013 12:59:33 PM zhu xiuming wrote: > > > Has someone done some work related to the performance impact of enabling > > > auditd on syscalls watching? > > > > Yes, long ago. > > http://people.redhat.com/sgrubb/files/lspp-perf.tar.gz > > > > Short story is watches were undistinguishable from cache hit/misses and > > syscall auditing gets more impact as more rules get added and based on how > > complicated the rule is. CPU's have changed so much since I did the > > benchmarking that I won't even hazard a guess as to what the performance > > hit > > is on current hardware with current kernel. > > > > -Steve