[PATCH] Better document profile=

[PATCH] Better document profile=

[Russ Dill]

Be more explicit on what the step/bucket size accomplishes.

Signed-off-by: Russ Dill <Russ.Dill@gmail.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
 			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)

 	processor.max_cstate=	[HW,ACPI]
-- 
1.5.2.5

Re: [PATCH] Better document profile=

[Andrew Morton]

On Tue, 16 Oct 2007 22:16:47 -0700
"Russ Dill" <russ.dill@gmail.com> wrote:

> Be more explicit on what the step/bucket size accomplishes.
> 
> Signed-off-by: Russ Dill <Russ.Dill@gmail.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.

>  			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).

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.

Re: [PATCH] Better document profile=

[Russ Dill]

On 10/25/07, Andrew Morton <akpm@linux-foundation.org> wrote:
> On Tue, 16 Oct 2007 22:16:47 -0700
> "Russ Dill" <russ.dill@gmail.com> wrote:
>
> > Be more explicit on what the step/bucket size accomplishes.
> >
> > Signed-off-by: Russ Dill <Russ.Dill@gmail.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)

Re: [PATCH] Better document profile=

[Andrew Morton]

On Thu, 25 Oct 2007 22:03:21 -0700 "Russ Dill" <russ.dill@gmail.com> wrote:

> > >                       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?

Just.  I seem to recall discussing this with someone a number of weeks ago.
Sorry, but my memory gets flushed a lot more frequently than that.

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

ok, you're right.