Re: Audit / Netlink slowness

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



>> 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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux