Possible performance bug

[Chris Wright]

* Amy Griffis (amy.griffis at hp.com) wrote:
> On Thu, Sep 08, 2005 at 04:31:02PM -0700, Chris Wright wrote:
> > * Steve Grubb (sgrubb at 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.