Be more explicit on what the step/bucket size accomplishes.
Signed-off-by: Russ Dill <[email protected]>
---
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
On Tue, 16 Oct 2007 22:16:47 -0700
"Russ Dill" <[email protected]> wrote:
> Be more explicit on what the step/bucket size accomplishes.
>
> Signed-off-by: Russ Dill <[email protected]>
> ---
> 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.
On 10/25/07, Andrew Morton <[email protected]> wrote:
> On Tue, 16 Oct 2007 22:16:47 -0700
> "Russ Dill" <[email protected]> wrote:
>
> > Be more explicit on what the step/bucket size accomplishes.
> >
> > Signed-off-by: Russ Dill <[email protected]>
> > ---
> > 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)
On Thu, 25 Oct 2007 22:03:21 -0700 "Russ Dill" <[email protected]> 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.