>> netlink in theory should be fast. No routing or collisions. > >I suppose so, but I don't know any other netlink user >I could compare with to make sure it's really a problem >specific to audit. It works very similar to any other netlink app, except its unicast, synchronous, and needs the netlink ack flag. This is because CAPP demands that if an event is not able to be audited, use of the system should be denied. From pam's perspective all that its concerned with is to send the audit event and see that the kernel has taken custody of the event. At that point its free to continue. >>>"su" connects to a NETLINK_AUDIT socket 3 or 4 times. >>>Each time it does 2 sendto() + recvfrom() operations, >> >> It does an audit subsystem status to see if its enabled and if so >> a send of auditable information. What version of pam, su, audit-libs, >> kernel are you using? > > pam-0.79-10 > audit-libs-0.9.3-1 > coreutils-5.2.1-31 > kernel-2.6.11-1.1240_FC4 These are all good. I released a new audit package that has 2 syscalls removed. You should see a performance improvement with audit-libs-0.9.5. >> Just out of curiosity, what cpu & clock speed do you have? > >It's an Athlon 2500 (3547.13 bogomips) Good thanks. This is useful info. >> This code path should be entirely cpu bound as no io devices are >> involved. > >Does the audit socket communication talk synchronously with >auditd? If so, the problem could be there too. Yes. It also waits for the ack flag. It has absolutely got to know that the kernel has the message. I did a review of the critical path in the kernel and found a few minor improvements. I'm still looking at it and may have some more improvements - but there's no big delay that I can see. >>>Is this behavior to be expected? >> >> Not exactly. There will be a *some* delay as we've added a lot >> of new functionality, but 800 ms total delay is excessive. I'll >> see if we can find the culprit. > >Could you please also try an "strace -r" to make sure I'm >not the only one seeing this? I don't doubt your claims. I have made improvements with the assumption that your results are reproducable. audit-libs-0.9.5 should behave better for you. I will also release 0.9.6 today and see if I can get some timing information. I am using a special kernel that has all the audit patches applied so my results may not hold for a FC4 kernel. Thanks for bringing this performance issue up. -Steve Grubb __________________________________ Discover Yahoo! Stay in touch with email, IM, photo sharing and more. Check it out! http://discover.yahoo.com/stayintouch.html -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-devel-list
