On Tue, Jul 04, 2017 at 09:23:55AM -0700, Deepa Dinamani wrote: > > The patch in question has no explanation as to why a fully-accurate > > timestamp > > is required and is likely an oversight. Using a coarser, but monotically > > increasing, timestamp the overhead can be eliminated. > > You are right. I was trying to use ktime_get* functions preferably. > I was aware that current_kernel_time64() could also be used if lesser > granularity was preferred and that it was faster. > I forgot to note that in the commit text. >
Given the severe overhead (roughly 10% to redis, sysbench-threads), would you be willing to accept the coarser granularity to avoid audit taking a major performance hit? I didn't mention it in my own changelog but a similar 10% hit is also visible in the will-it-scale microbenchmarks that focus on system calls so it's a fairly broad impact. -- Mel Gorman SUSE Labs
