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