Re: Possible performance bug
* Amy Griffis (amy.griffis(a)hp.com) wrote:
On Thu, Sep 08, 2005 at 04:31:02PM -0700, Chris Wright wrote:
> * Steve Grubb (sgrubb(a)redhat.com) wrote:
> > Don't all the running processes still have a context?
>
> Already running processes would (except those with 'never' rules), but
> news ones shouldn't (new meaning after -e0). It seems odd a benchmark
> that runs after -e0 (that's creating only new processes) would be that
> penalized. New processes would have no context, and existing processes
> would bail out of audit_syscall_entry. Profiles would be helpful.
The TIF_SYSCALL_AUDIT flag isn't explicitly cleared in copy_process,
so it continues to be propagated to new tasks once audit has been
enabled, regardless of the current value of the audit_enabled flag.
After -e0, new tasks still incur some extra overhead from trace
syscall processing instead of jumping out early. It would be
interesting to see some numbers on that.
Good point. In fact, audit_alloc should probably clear that if disabled.
But ISTR numbers of the order audit slows benchmarks down 20%. This is
not going to give 20% overhead. Probably measurable on a tight looping
getpid() micro benchmark, but (if the penalty is as large as I thought
was mentioned in the past) easily lost in a macro benchmark.