lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f9d2a5e10710252203n7ff40690j8d4822310826f9e8@mail.gmail.com>
Date:	Thu, 25 Oct 2007 22:03:21 -0700
From:	"Russ Dill" <russ.dill@...il.com>
To:	"Andrew Morton" <akpm@...ux-foundation.org>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Better document profile=

On 10/25/07, Andrew Morton <akpm@...ux-foundation.org> wrote:
> On Tue, 16 Oct 2007 22:16:47 -0700
> "Russ Dill" <russ.dill@...il.com> wrote:
>
> > Be more explicit on what the step/bucket size accomplishes.
> >
> > Signed-off-by: Russ Dill <Russ.Dill@...il.com>
> > ---
> >  Documentation/kernel-parameters.txt |    5 ++++-
> >  1 files changed, 4 insertions(+), 1 deletions(-)
> >
> > diff --git a/Documentation/kernel-parameters.txt
> > b/Documentation/kernel-parameters.txt
> > index eb24799..3c6fd27 100644
> > --- a/Documentation/kernel-parameters.txt
> > +++ b/Documentation/kernel-parameters.txt
> > @@ -1427,7 +1427,10 @@ and is between 256 and 4096 characters. It is
> > defined in the file
>
> Your email client is wordwrapping the patches.

Sorry, I had sent an updated email a couple minutes after this one
without the wrapping.

> >                       Format: [schedule,]<number>
> >                       Param: "schedule" - profile schedule points.
> >                       Param: <number> - step/bucket size as a power of 2 for
> > -                             statistical time based profiling.
> > +                             statistical time based profiling. A value of
> > +                             2 will provide a granularity of 4 bytes, a
> > +                             value of 3 will provide a granularity of 8
> > +                             bytes and so on.
> >                       Param: "sleep" - profile D-state sleeping (millisecs)
>
> Actually the prof_shift isn't in units of bytes: it is in units of
> sizeof(unsigned long).


I thought we just went through this?

extern char _text[], _stext[], _etext[];
[...]
prof_len = (_etext - _stext) >> prof_shift;
prof_buffer = alloc_bootmem(prof_len*sizeof(atomic_t));

1MB kernel, 32 bit, prof_shift = 2, makes for 262144 profiling slots,
a granularity of 4 bytes
1MB kernel, 64 bit, prof_shift = 2, makes for 262144 profiling slots,
a granularity of 4 bytes

The only difference between the two being the sizeof(atomic_t), so
that a 32 bit kernel would allocate a 1MB buffer, and a 64 bit kernel
would allocate a 2MB buffer. I'm having nightmares about megawords
again...

> So on a 64-bit kernel, prof_shift=2 will give a granularity of 8<<2 bytes
> and on a 32-bit kernel, prof_shift=3 will give a granularity of 4<<3 bytes.

now you are confusing me even more... by 8<<2 and 4<<3 do you mean 32
bytes? Linus says the following in 0.98:

# uncomment this if you want kernel profiling: the profile_shift is the
# granularity of the profiling (5 = 32-byte granularity)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ