From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752522AbdGDQxM (ORCPT ); Tue, 4 Jul 2017 12:53:12 -0400 Received: from outbound-smtp02.blacknight.com ([81.17.249.8]:47451 "EHLO outbound-smtp02.blacknight.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752394AbdGDQxK (ORCPT ); Tue, 4 Jul 2017 12:53:10 -0400 Date: Tue, 4 Jul 2017 17:53:08 +0100 From: Mel Gorman To: Deepa Dinamani Cc: Arnd Bergmann , Paul Moore , Richard Guy Briggs , Tony Jones , LKML Subject: Re: [PATCH] audit: Reduce overhead using a coarse clock Message-ID: <20170704165308.ls4i5qa4sz6cpn5x@techsingularity.net> References: <20170704121143.rvxkmm4rpphbyfd7@techsingularity.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170421 (1.8.2) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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