Re: Looking at profile data once again - avc lookup

From: Paul Moore <paul@paul-moore.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Stephen Smalley <stephen.smalley.work@gmail.com>,
	SElinux list <selinux@vger.kernel.org>
Subject: Re: Looking at profile data once again - avc lookup
Date: Mon, 30 Jan 2023 14:54:53 -0500	[thread overview]
Message-ID: <CAHC9VhSvmbSC9CraaipWjNmbZYadOcHQJ7oMjiieSc+Fv2Y+AA@mail.gmail.com> (raw)
In-Reply-To: <CAHk-=wiHX5wpnFSOgWNgNxMk+xHA2Gbh+7_eiJjTPGqpJ1kxog@mail.gmail.com>

On Mon, Jan 30, 2023 at 1:35 PM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Mon, Jan 30, 2023 at 9:47 AM Paul Moore <paul@paul-moore.com> wrote:
> >
> > I should add, do you have any particular test script you use?  If not,
> > that's fine, I just cobble something together, but I figured if you
> > had something already it would save me having to remember the details
> > on the perf tools.
>
> So I've done various things over the years, including just writing
> special tools that do nothing but a recursive 'stat()' over and over
> again over a big tree, just to pinpoint the path lookup costs (big
> enough of a tree that you see actual cache effects). Then do that
> either single-threaded or multi-threaded to see the locking issues.
>
> But what I keep coming back to is to just have a fully built "make
> allmodconfig" tree - which I have _anyway_, and then doing
>
>      perf record -e cycles:pp make -j64
>

...

> Put another way: there's nothing _special_ about the above, except for
> the "it's a real load that does actually show a few core kernel
> areas".

Thanks.

-- 
paul-moore.com