* [parisc-linux] [Testers wanted] New glibc with profiling fixed.
@ 2004-01-05 19:48 Carlos O'Donell
2004-01-05 19:48 ` Carlos O'Donell
` (5 more replies)
0 siblings, 6 replies; 33+ messages in thread
From: Carlos O'Donell @ 2004-01-05 19:48 UTC (permalink / raw)
To: parisc-linux, debian-hppa
pa'ers,
glibc 2.3.2.ds1-10
- Added profiling patches (Thanks Randolph!)
- Rebuilt glibc.
- Did not modify changelog or bump version.
Testers wanted please, in particular to test if building with -pg works
on your system and you get the expected results.
If testing goes well, these patches are going into debian-glibc's tree.
Cheers,
Carlos.
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [parisc-linux] [Testers wanted] New glibc with profiling fixed.
2004-01-05 19:48 [parisc-linux] [Testers wanted] New glibc with profiling fixed Carlos O'Donell
@ 2004-01-05 19:48 ` Carlos O'Donell
2004-01-11 4:09 ` Grant Grundler
2004-01-11 4:09 ` Grant Grundler
2004-01-05 19:48 ` Carlos O'Donell
` (4 subsequent siblings)
5 siblings, 2 replies; 33+ messages in thread
From: Carlos O'Donell @ 2004-01-05 19:48 UTC (permalink / raw)
To: parisc-linux, debian-hppa
On Mon, Jan 05, 2004 at 02:48:09PM -0500, Carlos O'Donell wrote:
>
> pa'ers,
>
> glibc 2.3.2.ds1-10
>
> - Added profiling patches (Thanks Randolph!)
> - Rebuilt glibc.
> - Did not modify changelog or bump version.
>
> Testers wanted please, in particular to test if building with -pg works
> on your system and you get the expected results.
>
> If testing goes well, these patches are going into debian-glibc's tree.
Oh yeah...
http://www.parisc-linux.org/~carlos/glibc-2.3.2-debs-2004-01-05/
c.
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [parisc-linux] [Testers wanted] New glibc with profiling fixed.
2004-01-05 19:48 [parisc-linux] [Testers wanted] New glibc with profiling fixed Carlos O'Donell
2004-01-05 19:48 ` Carlos O'Donell
@ 2004-01-05 19:48 ` Carlos O'Donell
2004-01-05 20:45 ` Grant Grundler
` (3 subsequent siblings)
5 siblings, 0 replies; 33+ messages in thread
From: Carlos O'Donell @ 2004-01-05 19:48 UTC (permalink / raw)
To: parisc-linux, debian-hppa
On Mon, Jan 05, 2004 at 02:48:09PM -0500, Carlos O'Donell wrote:
>
> pa'ers,
>
> glibc 2.3.2.ds1-10
>
> - Added profiling patches (Thanks Randolph!)
> - Rebuilt glibc.
> - Did not modify changelog or bump version.
>
> Testers wanted please, in particular to test if building with -pg works
> on your system and you get the expected results.
>
> If testing goes well, these patches are going into debian-glibc's tree.
Oh yeah...
http://www.parisc-linux.org/~carlos/glibc-2.3.2-debs-2004-01-05/
c.
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [parisc-linux] [Testers wanted] New glibc with profiling fixed.
2004-01-05 19:48 [parisc-linux] [Testers wanted] New glibc with profiling fixed Carlos O'Donell
2004-01-05 19:48 ` Carlos O'Donell
2004-01-05 19:48 ` Carlos O'Donell
@ 2004-01-05 20:45 ` Grant Grundler
2004-01-05 22:00 ` Carlos O'Donell
2004-01-05 22:00 ` Carlos O'Donell
2004-01-05 20:45 ` Grant Grundler
` (2 subsequent siblings)
5 siblings, 2 replies; 33+ messages in thread
From: Grant Grundler @ 2004-01-05 20:45 UTC (permalink / raw)
To: Carlos O'Donell; +Cc: parisc-linux, debian-hppa
On Mon, Jan 05, 2004 at 02:48:09PM -0500, Carlos O'Donell wrote:
> Testers wanted please, in particular to test if building with -pg works
> on your system and you get the expected results.
How much testing has this had?
I'm willing to try it on various boxes if I have an idea
of the risk involved.
thanks,
grant
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [parisc-linux] [Testers wanted] New glibc with profiling fixed.
2004-01-05 19:48 [parisc-linux] [Testers wanted] New glibc with profiling fixed Carlos O'Donell
` (2 preceding siblings ...)
2004-01-05 20:45 ` Grant Grundler
@ 2004-01-05 20:45 ` Grant Grundler
2004-01-07 21:04 ` John David Anglin
2004-01-07 21:04 ` John David Anglin
5 siblings, 0 replies; 33+ messages in thread
From: Grant Grundler @ 2004-01-05 20:45 UTC (permalink / raw)
To: Carlos O'Donell; +Cc: parisc-linux, debian-hppa
On Mon, Jan 05, 2004 at 02:48:09PM -0500, Carlos O'Donell wrote:
> Testers wanted please, in particular to test if building with -pg works
> on your system and you get the expected results.
How much testing has this had?
I'm willing to try it on various boxes if I have an idea
of the risk involved.
thanks,
grant
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [parisc-linux] [Testers wanted] New glibc with profiling fixed.
2004-01-05 20:45 ` Grant Grundler
@ 2004-01-05 22:00 ` Carlos O'Donell
2004-01-05 22:00 ` Carlos O'Donell
1 sibling, 0 replies; 33+ messages in thread
From: Carlos O'Donell @ 2004-01-05 22:00 UTC (permalink / raw)
To: Grant Grundler; +Cc: parisc-linux, debian-hppa
On Mon, Jan 05, 2004 at 01:45:10PM -0700, Grant Grundler wrote:
> On Mon, Jan 05, 2004 at 02:48:09PM -0500, Carlos O'Donell wrote:
> > Testers wanted please, in particular to test if building with -pg works
> > on your system and you get the expected results.
>
> How much testing has this had?
> I'm willing to try it on various boxes if I have an idea
> of the risk involved.
Passes all the testsuites without regressions. Doesn't kill *my* system.
It's a *minor* change to the existing glibc provided by debian, purely
to fix the FTBS that lamont saw for "roy."
c.
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [parisc-linux] [Testers wanted] New glibc with profiling fixed.
2004-01-05 20:45 ` Grant Grundler
2004-01-05 22:00 ` Carlos O'Donell
@ 2004-01-05 22:00 ` Carlos O'Donell
1 sibling, 0 replies; 33+ messages in thread
From: Carlos O'Donell @ 2004-01-05 22:00 UTC (permalink / raw)
To: Grant Grundler; +Cc: parisc-linux, debian-hppa
On Mon, Jan 05, 2004 at 01:45:10PM -0700, Grant Grundler wrote:
> On Mon, Jan 05, 2004 at 02:48:09PM -0500, Carlos O'Donell wrote:
> > Testers wanted please, in particular to test if building with -pg works
> > on your system and you get the expected results.
>
> How much testing has this had?
> I'm willing to try it on various boxes if I have an idea
> of the risk involved.
Passes all the testsuites without regressions. Doesn't kill *my* system.
It's a *minor* change to the existing glibc provided by debian, purely
to fix the FTBS that lamont saw for "roy."
c.
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [parisc-linux] [Testers wanted] New glibc with profiling fixed.
2004-01-05 19:48 [parisc-linux] [Testers wanted] New glibc with profiling fixed Carlos O'Donell
` (4 preceding siblings ...)
2004-01-07 21:04 ` John David Anglin
@ 2004-01-07 21:04 ` John David Anglin
5 siblings, 0 replies; 33+ messages in thread
From: John David Anglin @ 2004-01-07 21:04 UTC (permalink / raw)
To: Carlos O'Donell; +Cc: parisc-linux, debian-hppa
> glibc 2.3.2.ds1-10
>
> - Added profiling patches (Thanks Randolph!)
The GCC profiling tests still segfault. It looks like crtn.o
hasn't been updated. Did I miss something?
Dave
--
J. David Anglin dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6602)
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [parisc-linux] [Testers wanted] New glibc with profiling fixed.
2004-01-05 19:48 [parisc-linux] [Testers wanted] New glibc with profiling fixed Carlos O'Donell
` (3 preceding siblings ...)
2004-01-05 20:45 ` Grant Grundler
@ 2004-01-07 21:04 ` John David Anglin
2004-01-07 21:04 ` John David Anglin
5 siblings, 0 replies; 33+ messages in thread
From: John David Anglin @ 2004-01-07 21:04 UTC (permalink / raw)
To: Carlos O'Donell; +Cc: parisc-linux, debian-hppa
> glibc 2.3.2.ds1-10
>
> - Added profiling patches (Thanks Randolph!)
The GCC profiling tests still segfault. It looks like crtn.o
hasn't been updated. Did I miss something?
Dave
--
J. David Anglin dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6602)
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [parisc-linux] [Testers wanted] New glibc with profiling fixed.
2004-01-05 19:48 ` Carlos O'Donell
@ 2004-01-11 4:09 ` Grant Grundler
2004-01-11 20:43 ` Carlos O'Donell
2004-01-11 20:43 ` Carlos O'Donell
2004-01-11 4:09 ` Grant Grundler
1 sibling, 2 replies; 33+ messages in thread
From: Grant Grundler @ 2004-01-11 4:09 UTC (permalink / raw)
To: Carlos O'Donell; +Cc: parisc-linux, debian-hppa
On Mon, Jan 05, 2004 at 02:48:39PM -0500, Carlos O'Donell wrote:
> http://www.parisc-linux.org/~carlos/glibc-2.3.2-debs-2004-01-05/
I finally installed these (libc6 and libc6-dev) and live is still good.
thanks carlos!
hth,
grant
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [parisc-linux] [Testers wanted] New glibc with profiling fixed.
2004-01-05 19:48 ` Carlos O'Donell
2004-01-11 4:09 ` Grant Grundler
@ 2004-01-11 4:09 ` Grant Grundler
1 sibling, 0 replies; 33+ messages in thread
From: Grant Grundler @ 2004-01-11 4:09 UTC (permalink / raw)
To: Carlos O'Donell; +Cc: parisc-linux, debian-hppa
On Mon, Jan 05, 2004 at 02:48:39PM -0500, Carlos O'Donell wrote:
> http://www.parisc-linux.org/~carlos/glibc-2.3.2-debs-2004-01-05/
I finally installed these (libc6 and libc6-dev) and live is still good.
thanks carlos!
hth,
grant
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [parisc-linux] [Testers wanted] New glibc with profiling fixed.
2004-01-11 4:09 ` Grant Grundler
2004-01-11 20:43 ` Carlos O'Donell
@ 2004-01-11 20:43 ` Carlos O'Donell
2004-01-12 16:38 ` Grant Grundler
` (5 more replies)
1 sibling, 6 replies; 33+ messages in thread
From: Carlos O'Donell @ 2004-01-11 20:43 UTC (permalink / raw)
To: Grant Grundler; +Cc: parisc-linux, debian-hppa
On Sat, Jan 10, 2004 at 09:09:06PM -0700, Grant Grundler wrote:
> On Mon, Jan 05, 2004 at 02:48:39PM -0500, Carlos O'Donell wrote:
> > http://www.parisc-linux.org/~carlos/glibc-2.3.2-debs-2004-01-05/
>
> I finally installed these (libc6 and libc6-dev) and live is still good.
> thanks carlos!
Excellent. You haven't tried profiling any programs have you? :)
Compile with CFLAGS=-pg, run-em, then run gprof on the gmon.out output?
c.
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [parisc-linux] [Testers wanted] New glibc with profiling fixed.
2004-01-11 4:09 ` Grant Grundler
@ 2004-01-11 20:43 ` Carlos O'Donell
2004-01-11 20:43 ` Carlos O'Donell
1 sibling, 0 replies; 33+ messages in thread
From: Carlos O'Donell @ 2004-01-11 20:43 UTC (permalink / raw)
To: Grant Grundler; +Cc: parisc-linux, debian-hppa
On Sat, Jan 10, 2004 at 09:09:06PM -0700, Grant Grundler wrote:
> On Mon, Jan 05, 2004 at 02:48:39PM -0500, Carlos O'Donell wrote:
> > http://www.parisc-linux.org/~carlos/glibc-2.3.2-debs-2004-01-05/
>
> I finally installed these (libc6 and libc6-dev) and live is still good.
> thanks carlos!
Excellent. You haven't tried profiling any programs have you? :)
Compile with CFLAGS=-pg, run-em, then run gprof on the gmon.out output?
c.
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [parisc-linux] [Testers wanted] New glibc with profiling fixed.
2004-01-11 20:43 ` Carlos O'Donell
2004-01-12 16:38 ` Grant Grundler
@ 2004-01-12 16:38 ` Grant Grundler
2004-01-13 5:42 ` Grant Grundler
` (3 subsequent siblings)
5 siblings, 0 replies; 33+ messages in thread
From: Grant Grundler @ 2004-01-12 16:38 UTC (permalink / raw)
To: Carlos O'Donell; +Cc: parisc-linux, debian-hppa
On Sun, Jan 11, 2004 at 03:43:55PM -0500, Carlos O'Donell wrote:
> Excellent. You haven't tried profiling any programs have you? :)
Profiing? what's that? :^P
> Compile with CFLAGS=-pg, run-em, then run gprof on the gmon.out output?
ok...I'll try tonight.
thanks,
grant
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [parisc-linux] [Testers wanted] New glibc with profiling fixed.
2004-01-11 20:43 ` Carlos O'Donell
@ 2004-01-12 16:38 ` Grant Grundler
2004-01-12 16:38 ` Grant Grundler
` (4 subsequent siblings)
5 siblings, 0 replies; 33+ messages in thread
From: Grant Grundler @ 2004-01-12 16:38 UTC (permalink / raw)
To: Carlos O'Donell; +Cc: parisc-linux, debian-hppa
On Sun, Jan 11, 2004 at 03:43:55PM -0500, Carlos O'Donell wrote:
> Excellent. You haven't tried profiling any programs have you? :)
Profiing? what's that? :^P
> Compile with CFLAGS=-pg, run-em, then run gprof on the gmon.out output?
ok...I'll try tonight.
thanks,
grant
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [parisc-linux] [Testers wanted] New glibc with profiling fixed.
2004-01-11 20:43 ` Carlos O'Donell
` (2 preceding siblings ...)
2004-01-13 5:42 ` Grant Grundler
@ 2004-01-13 5:42 ` Grant Grundler
2004-01-13 8:46 ` Joel Soete
2004-01-13 8:46 ` Joel Soete
5 siblings, 0 replies; 33+ messages in thread
From: Grant Grundler @ 2004-01-13 5:42 UTC (permalink / raw)
To: Carlos O'Donell; +Cc: parisc-linux, debian-hppa
On Sun, Jan 11, 2004 at 03:43:55PM -0500, Carlos O'Donell wrote:
> Excellent. You haven't tried profiling any programs have you? :)
> Compile with CFLAGS=-pg, run-em, then run gprof on the gmon.out output?
Here's "apps/openssl speed rsa" gprof output from my c3000.
(2.6.0-pa7, Debian testing)
TBH, it looks wrong.
I didn't expect "get_dsa1024" to show up.
I suspect I didn't get all the various CFLAGS.
I edited */Makefile and added -pg by hand to "CFLAG" variables
and then "make clean" + "make".
hth,
grant
Flat profile:
Each sample counts as 0.01 seconds.
% cumulative self self total
time seconds seconds calls Ts/call Ts/call name
63.64 0.07 0.07 lock_dbg_cb
27.27 0.10 0.03 check_end
9.09 0.11 0.01 call_frame_dummy
0.00 0.11 0.00 16 0.00 0.00 Time_F
0.00 0.11 0.00 8 0.00 0.00 pkey_print_message
0.00 0.11 0.00 1 0.00 0.00 destroy_ui_method
0.00 0.11 0.00 1 0.00 0.00 do_cmd
0.00 0.11 0.00 1 0.00 0.00 get_dsa1024
0.00 0.11 0.00 1 0.00 0.00 get_dsa2048
0.00 0.11 0.00 1 0.00 0.00 get_dsa512
0.00 0.11 0.00 1 0.00 0.00 load_config
0.00 0.11 0.00 1 0.00 0.00 make_config_name
0.00 0.11 0.00 1 0.00 0.00 prog_init
0.00 0.11 0.00 1 0.00 0.00 program_name
0.00 0.11 0.00 1 0.00 0.00 setup_ui_method
0.00 0.11 0.00 1 0.00 0.00 speed_main
% the percentage of the total running time of the
time program used by this function.
cumulative a running sum of the number of seconds accounted
seconds for by this function and those listed above it.
self the number of seconds accounted for by this
seconds function alone. This is the major sort for this
listing.
calls the number of times this function was invoked, if
this function is profiled, else blank.
self the average number of milliseconds spent in this
ms/call function per call, if this function is profiled,
else blank.
total the average number of milliseconds spent in this
ms/call function and its descendents per call, if this
function is profiled, else blank.
name the name of the function. This is the minor sort
for this listing. The index shows the location of
the function in the gprof listing. If the index is
in parenthesis it shows where it would appear in
the gprof listing if it were to be printed.
\f
Call graph (explanation follows)
granularity: each sample hit covers 2 byte(s) for 9.09% of 0.11 seconds
index % time self children called name
<spontaneous>
[1] 63.6 0.07 0.00 lock_dbg_cb [1]
-----------------------------------------------
<spontaneous>
[2] 27.3 0.03 0.00 check_end [2]
-----------------------------------------------
<spontaneous>
[3] 9.1 0.01 0.00 call_frame_dummy [3]
-----------------------------------------------
0.00 0.00 16/16 speed_main [16]
[4] 0.0 0.00 0.00 16 Time_F [4]
-----------------------------------------------
0.00 0.00 8/8 speed_main [16]
[5] 0.0 0.00 0.00 8 pkey_print_message [5]
-----------------------------------------------
0.00 0.00 1/1 main [131]
[6] 0.0 0.00 0.00 1 destroy_ui_method [6]
-----------------------------------------------
0.00 0.00 1/1 main [131]
[7] 0.0 0.00 0.00 1 do_cmd [7]
0.00 0.00 1/1 speed_main [16]
-----------------------------------------------
0.00 0.00 1/1 speed_main [16]
[8] 0.0 0.00 0.00 1 get_dsa1024 [8]
-----------------------------------------------
0.00 0.00 1/1 speed_main [16]
[9] 0.0 0.00 0.00 1 get_dsa2048 [9]
-----------------------------------------------
0.00 0.00 1/1 speed_main [16]
[10] 0.0 0.00 0.00 1 get_dsa512 [10]
-----------------------------------------------
0.00 0.00 1/1 speed_main [16]
[11] 0.0 0.00 0.00 1 load_config [11]
-----------------------------------------------
0.00 0.00 1/1 main [131]
[12] 0.0 0.00 0.00 1 make_config_name [12]
-----------------------------------------------
0.00 0.00 1/1 main [131]
[13] 0.0 0.00 0.00 1 prog_init [13]
-----------------------------------------------
0.00 0.00 1/1 main [131]
[14] 0.0 0.00 0.00 1 program_name [14]
-----------------------------------------------
0.00 0.00 1/1 main [131]
[15] 0.0 0.00 0.00 1 setup_ui_method [15]
-----------------------------------------------
0.00 0.00 1/1 do_cmd [7]
[16] 0.0 0.00 0.00 1 speed_main [16]
0.00 0.00 16/16 Time_F [4]
0.00 0.00 8/8 pkey_print_message [5]
0.00 0.00 1/1 load_config [11]
0.00 0.00 1/1 get_dsa512 [10]
0.00 0.00 1/1 get_dsa1024 [8]
0.00 0.00 1/1 get_dsa2048 [9]
-----------------------------------------------
This table describes the call tree of the program, and was sorted by
the total amount of time spent in each function and its children.
Each entry in this table consists of several lines. The line with the
index number at the left hand margin lists the current function.
The lines above it list the functions that called this function,
and the lines below it list the functions this one called.
This line lists:
index A unique number given to each element of the table.
Index numbers are sorted numerically.
The index number is printed next to every function name so
it is easier to look up where the function in the table.
% time This is the percentage of the `total' time that was spent
in this function and its children. Note that due to
different viewpoints, functions excluded by options, etc,
these numbers will NOT add up to 100%.
self This is the total amount of time spent in this function.
children This is the total amount of time propagated into this
function by its children.
called This is the number of times the function was called.
If the function called itself recursively, the number
only includes non-recursive calls, and is followed by
a `+' and the number of recursive calls.
name The name of the current function. The index number is
printed after it. If the function is a member of a
cycle, the cycle number is printed between the
function's name and the index number.
For the function's parents, the fields have the following meanings:
self This is the amount of time that was propagated directly
from the function into this parent.
children This is the amount of time that was propagated from
the function's children into this parent.
called This is the number of times this parent called the
function `/' the total number of times the function
was called. Recursive calls to the function are not
included in the number after the `/'.
name This is the name of the parent. The parent's index
number is printed after it. If the parent is a
member of a cycle, the cycle number is printed between
the name and the index number.
If the parents of the function cannot be determined, the word
`<spontaneous>' is printed in the `name' field, and all the other
fields are blank.
For the function's children, the fields have the following meanings:
self This is the amount of time that was propagated directly
from the child into the function.
children This is the amount of time that was propagated from the
child's children to the function.
called This is the number of times the function called
this child `/' the total number of times the child
was called. Recursive calls by the child are not
listed in the number after the `/'.
name This is the name of the child. The child's index
number is printed after it. If the child is a
member of a cycle, the cycle number is printed
between the name and the index number.
If there are any cycles (circles) in the call graph, there is an
entry for the cycle-as-a-whole. This entry shows who called the
cycle (as parents) and the members of the cycle (as children.)
The `+' recursive calls entry shows the number of function calls that
were internal to the cycle, and the calls entry for each member shows,
for that member, how many times it was called from other members of
the cycle.
\f
Index by function name
[4] Time_F [9] get_dsa2048 [13] prog_init
[3] call_frame_dummy [10] get_dsa512 [14] program_name
[2] check_end [11] load_config [15] setup_ui_method
[6] destroy_ui_method [1] lock_dbg_cb [16] speed_main
[7] do_cmd [12] make_config_name
[8] get_dsa1024 [5] pkey_print_message
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [parisc-linux] [Testers wanted] New glibc with profiling fixed.
2004-01-11 20:43 ` Carlos O'Donell
2004-01-12 16:38 ` Grant Grundler
2004-01-12 16:38 ` Grant Grundler
@ 2004-01-13 5:42 ` Grant Grundler
2004-01-13 5:42 ` Grant Grundler
` (2 subsequent siblings)
5 siblings, 0 replies; 33+ messages in thread
From: Grant Grundler @ 2004-01-13 5:42 UTC (permalink / raw)
To: Carlos O'Donell; +Cc: parisc-linux, debian-hppa
On Sun, Jan 11, 2004 at 03:43:55PM -0500, Carlos O'Donell wrote:
> Excellent. You haven't tried profiling any programs have you? :)
> Compile with CFLAGS=-pg, run-em, then run gprof on the gmon.out output?
Here's "apps/openssl speed rsa" gprof output from my c3000.
(2.6.0-pa7, Debian testing)
TBH, it looks wrong.
I didn't expect "get_dsa1024" to show up.
I suspect I didn't get all the various CFLAGS.
I edited */Makefile and added -pg by hand to "CFLAG" variables
and then "make clean" + "make".
hth,
grant
Flat profile:
Each sample counts as 0.01 seconds.
% cumulative self self total
time seconds seconds calls Ts/call Ts/call name
63.64 0.07 0.07 lock_dbg_cb
27.27 0.10 0.03 check_end
9.09 0.11 0.01 call_frame_dummy
0.00 0.11 0.00 16 0.00 0.00 Time_F
0.00 0.11 0.00 8 0.00 0.00 pkey_print_message
0.00 0.11 0.00 1 0.00 0.00 destroy_ui_method
0.00 0.11 0.00 1 0.00 0.00 do_cmd
0.00 0.11 0.00 1 0.00 0.00 get_dsa1024
0.00 0.11 0.00 1 0.00 0.00 get_dsa2048
0.00 0.11 0.00 1 0.00 0.00 get_dsa512
0.00 0.11 0.00 1 0.00 0.00 load_config
0.00 0.11 0.00 1 0.00 0.00 make_config_name
0.00 0.11 0.00 1 0.00 0.00 prog_init
0.00 0.11 0.00 1 0.00 0.00 program_name
0.00 0.11 0.00 1 0.00 0.00 setup_ui_method
0.00 0.11 0.00 1 0.00 0.00 speed_main
% the percentage of the total running time of the
time program used by this function.
cumulative a running sum of the number of seconds accounted
seconds for by this function and those listed above it.
self the number of seconds accounted for by this
seconds function alone. This is the major sort for this
listing.
calls the number of times this function was invoked, if
this function is profiled, else blank.
self the average number of milliseconds spent in this
ms/call function per call, if this function is profiled,
else blank.
total the average number of milliseconds spent in this
ms/call function and its descendents per call, if this
function is profiled, else blank.
name the name of the function. This is the minor sort
for this listing. The index shows the location of
the function in the gprof listing. If the index is
in parenthesis it shows where it would appear in
the gprof listing if it were to be printed.
\f
Call graph (explanation follows)
granularity: each sample hit covers 2 byte(s) for 9.09% of 0.11 seconds
index % time self children called name
<spontaneous>
[1] 63.6 0.07 0.00 lock_dbg_cb [1]
-----------------------------------------------
<spontaneous>
[2] 27.3 0.03 0.00 check_end [2]
-----------------------------------------------
<spontaneous>
[3] 9.1 0.01 0.00 call_frame_dummy [3]
-----------------------------------------------
0.00 0.00 16/16 speed_main [16]
[4] 0.0 0.00 0.00 16 Time_F [4]
-----------------------------------------------
0.00 0.00 8/8 speed_main [16]
[5] 0.0 0.00 0.00 8 pkey_print_message [5]
-----------------------------------------------
0.00 0.00 1/1 main [131]
[6] 0.0 0.00 0.00 1 destroy_ui_method [6]
-----------------------------------------------
0.00 0.00 1/1 main [131]
[7] 0.0 0.00 0.00 1 do_cmd [7]
0.00 0.00 1/1 speed_main [16]
-----------------------------------------------
0.00 0.00 1/1 speed_main [16]
[8] 0.0 0.00 0.00 1 get_dsa1024 [8]
-----------------------------------------------
0.00 0.00 1/1 speed_main [16]
[9] 0.0 0.00 0.00 1 get_dsa2048 [9]
-----------------------------------------------
0.00 0.00 1/1 speed_main [16]
[10] 0.0 0.00 0.00 1 get_dsa512 [10]
-----------------------------------------------
0.00 0.00 1/1 speed_main [16]
[11] 0.0 0.00 0.00 1 load_config [11]
-----------------------------------------------
0.00 0.00 1/1 main [131]
[12] 0.0 0.00 0.00 1 make_config_name [12]
-----------------------------------------------
0.00 0.00 1/1 main [131]
[13] 0.0 0.00 0.00 1 prog_init [13]
-----------------------------------------------
0.00 0.00 1/1 main [131]
[14] 0.0 0.00 0.00 1 program_name [14]
-----------------------------------------------
0.00 0.00 1/1 main [131]
[15] 0.0 0.00 0.00 1 setup_ui_method [15]
-----------------------------------------------
0.00 0.00 1/1 do_cmd [7]
[16] 0.0 0.00 0.00 1 speed_main [16]
0.00 0.00 16/16 Time_F [4]
0.00 0.00 8/8 pkey_print_message [5]
0.00 0.00 1/1 load_config [11]
0.00 0.00 1/1 get_dsa512 [10]
0.00 0.00 1/1 get_dsa1024 [8]
0.00 0.00 1/1 get_dsa2048 [9]
-----------------------------------------------
This table describes the call tree of the program, and was sorted by
the total amount of time spent in each function and its children.
Each entry in this table consists of several lines. The line with the
index number at the left hand margin lists the current function.
The lines above it list the functions that called this function,
and the lines below it list the functions this one called.
This line lists:
index A unique number given to each element of the table.
Index numbers are sorted numerically.
The index number is printed next to every function name so
it is easier to look up where the function in the table.
% time This is the percentage of the `total' time that was spent
in this function and its children. Note that due to
different viewpoints, functions excluded by options, etc,
these numbers will NOT add up to 100%.
self This is the total amount of time spent in this function.
children This is the total amount of time propagated into this
function by its children.
called This is the number of times the function was called.
If the function called itself recursively, the number
only includes non-recursive calls, and is followed by
a `+' and the number of recursive calls.
name The name of the current function. The index number is
printed after it. If the function is a member of a
cycle, the cycle number is printed between the
function's name and the index number.
For the function's parents, the fields have the following meanings:
self This is the amount of time that was propagated directly
from the function into this parent.
children This is the amount of time that was propagated from
the function's children into this parent.
called This is the number of times this parent called the
function `/' the total number of times the function
was called. Recursive calls to the function are not
included in the number after the `/'.
name This is the name of the parent. The parent's index
number is printed after it. If the parent is a
member of a cycle, the cycle number is printed between
the name and the index number.
If the parents of the function cannot be determined, the word
`<spontaneous>' is printed in the `name' field, and all the other
fields are blank.
For the function's children, the fields have the following meanings:
self This is the amount of time that was propagated directly
from the child into the function.
children This is the amount of time that was propagated from the
child's children to the function.
called This is the number of times the function called
this child `/' the total number of times the child
was called. Recursive calls by the child are not
listed in the number after the `/'.
name This is the name of the child. The child's index
number is printed after it. If the child is a
member of a cycle, the cycle number is printed
between the name and the index number.
If there are any cycles (circles) in the call graph, there is an
entry for the cycle-as-a-whole. This entry shows who called the
cycle (as parents) and the members of the cycle (as children.)
The `+' recursive calls entry shows the number of function calls that
were internal to the cycle, and the calls entry for each member shows,
for that member, how many times it was called from other members of
the cycle.
\f
Index by function name
[4] Time_F [9] get_dsa2048 [13] prog_init
[3] call_frame_dummy [10] get_dsa512 [14] program_name
[2] check_end [11] load_config [15] setup_ui_method
[6] destroy_ui_method [1] lock_dbg_cb [16] speed_main
[7] do_cmd [12] make_config_name
[8] get_dsa1024 [5] pkey_print_message
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [parisc-linux] [Testers wanted] New glibc with profiling fixed.
2004-01-11 20:43 ` Carlos O'Donell
` (4 preceding siblings ...)
2004-01-13 8:46 ` Joel Soete
@ 2004-01-13 8:46 ` Joel Soete
5 siblings, 0 replies; 33+ messages in thread
From: Joel Soete @ 2004-01-13 8:46 UTC (permalink / raw)
To: Carlos O'Donell, Grant Grundler; +Cc: parisc-linux, debian-hppa
Hi Carlos,
btw may I ask your patch so that I can test it in my tc process (and why
not trying profiling on kernel build ;) )
Thanks in advance,
Joel
>-- Original Message --
>Date: Sun, 11 Jan 2004 15:43:55 -0500
>From: Carlos O'Donell <carlos@baldric.uwo.ca>
>To: Grant Grundler <grundler@parisc-linux.org>
>Cc: parisc-linux@lists.parisc-linux.org, debian-hppa@lists.debian.org
>Subject: Re: [parisc-linux] [Testers wanted] New glibc with profiling fixed.
>
>
>On Sat, Jan 10, 2004 at 09:09:06PM -0700, Grant Grundler wrote:
> On Mon, Jan 05, 2004 at 02:48:39PM -0500, Carlos O'Donell wrote:
> > http://www.parisc-linux.org/~carlos/glibc-2.3.2-debs-2004-01-05/
>
> I finally installed these (libc6 and libc6-
>ev) and live is still good.
> thanks carlos!
Excellent. You haven't tried profiling any programs have you? :)
Compile with CFLAGS=-pg, run-em, then run gprof on the gmon.out output?
c.
_______________________________________________
parisc-
>inux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
-------------------------------------------------------------------------
Tiscali ADSL: 12 mois à 29,50 /mois! L'Internet rapide, c'est pour tout
le monde.
http://reg.tiscali.be/default.asp?lg=fr
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [parisc-linux] [Testers wanted] New glibc with profiling fixed.
2004-01-11 20:43 ` Carlos O'Donell
` (3 preceding siblings ...)
2004-01-13 5:42 ` Grant Grundler
@ 2004-01-13 8:46 ` Joel Soete
2004-01-13 8:46 ` Joel Soete
5 siblings, 0 replies; 33+ messages in thread
From: Joel Soete @ 2004-01-13 8:46 UTC (permalink / raw)
To: Carlos O'Donell, Grant Grundler; +Cc: parisc-linux, debian-hppa
Hi Carlos,
btw may I ask your patch so that I can test it in my tc process (and why
not trying profiling on kernel build ;) )
Thanks in advance,
Joel
>-- Original Message --
>Date: Sun, 11 Jan 2004 15:43:55 -0500
>From: Carlos O'Donell <carlos@baldric.uwo.ca>
>To: Grant Grundler <grundler@parisc-linux.org>
>Cc: parisc-linux@lists.parisc-linux.org, debian-hppa@lists.debian.org
>Subject: Re: [parisc-linux] [Testers wanted] New glibc with profiling fixed.
>
>
>On Sat, Jan 10, 2004 at 09:09:06PM -0700, Grant Grundler wrote:
> On Mon, Jan 05, 2004 at 02:48:39PM -0500, Carlos O'Donell wrote:
> > http://www.parisc-linux.org/~carlos/glibc-2.3.2-debs-2004-01-05/
>
> I finally installed these (libc6 and libc6-
>ev) and live is still good.
> thanks carlos!
Excellent. You haven't tried profiling any programs have you? :)
Compile with CFLAGS=-pg, run-em, then run gprof on the gmon.out output?
c.
_______________________________________________
parisc-
>inux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
-------------------------------------------------------------------------
Tiscali ADSL: 12 mois à 29,50 /mois! L'Internet rapide, c'est pour tout
le monde.
http://reg.tiscali.be/default.asp?lg=fr
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [parisc-linux] [Testers wanted] New glibc with profiling fixed.
2005-07-26 17:09 ` Matthew Wilcox
@ 2005-07-26 18:08 ` Carlos O'Donell
0 siblings, 0 replies; 33+ messages in thread
From: Carlos O'Donell @ 2005-07-26 18:08 UTC (permalink / raw)
To: Matthew Wilcox; +Cc: Tres Melton, parisc-linux
On Tue, Jul 26, 2005 at 06:09:49PM +0100, Matthew Wilcox wrote:
> > IMO any interface exporting/using ticks is broken. Accurate time can
> > be provided through other interfaces. Userspace should never see ticks,
> > only converted time.
>
> userspace should see converted ticks. ie divide by 10 if CONFIG_HZ is 1000
> since PA userspace expects to see 100Hz.
I meant "ideologicall" broken. Yes, converting ticks to an expected
value preserves userspace compatibility.
gprof may want to stop using times() when a more suitable interface
becomes available.
c.
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [parisc-linux] [Testers wanted] New glibc with profiling fixed.
2005-07-26 14:18 ` Matthew Wilcox
2005-07-26 14:25 ` Randolph Chung
2005-07-26 15:26 ` Tres Melton
@ 2005-07-26 17:16 ` Carlos O'Donell
2 siblings, 0 replies; 33+ messages in thread
From: Carlos O'Donell @ 2005-07-26 17:16 UTC (permalink / raw)
To: Matthew Wilcox; +Cc: Tres Melton, parisc-linux
On Tue, Jul 26, 2005 at 03:18:37PM +0100, Matthew Wilcox wrote:
> On Tue, Jul 26, 2005 at 07:37:16AM -0600, Tres Melton wrote:
> > I'm advocating a way for user space to *know* what the kernel is
> > running. It is this thinking crap that is messing things up.
>
> User space should not "know" what HZ the kernel is using. Instead, all
> interfaces should be properly reported in terms of whatever HZ userspace
> used to assume (100 on i386, other values on other platforms). I don't
> know what interface gprof is using, but it needs to be fixed.
>
> Otherwise we stand no chance of going to a dynamic HZ in the future.
Or better yet a precise time interface with feedback about the accuracy
of the returned time.
For example, while cr16 on parisc is a very precise measurement of insn
execution speed, it varies too much to be used for a stable and accurate
global clock.
c.
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [parisc-linux] [Testers wanted] New glibc with profiling fixed.
2005-07-26 17:01 ` Carlos O'Donell
@ 2005-07-26 17:09 ` Matthew Wilcox
2005-07-26 18:08 ` Carlos O'Donell
0 siblings, 1 reply; 33+ messages in thread
From: Matthew Wilcox @ 2005-07-26 17:09 UTC (permalink / raw)
To: Carlos O'Donell; +Cc: Tres Melton, parisc-linux, Matthew Wilcox
On Tue, Jul 26, 2005 at 01:01:35PM -0400, Carlos O'Donell wrote:
> On Tue, Jul 26, 2005 at 10:25:44PM +0800, Randolph Chung wrote:
> > >User space should not "know" what HZ the kernel is using. Instead, all
> > >interfaces should be properly reported in terms of whatever HZ userspace
> > >used to assume (100 on i386, other values on other platforms). I don't
> > >know what interface gprof is using, but it needs to be fixed.
> >
> > I thought gprof uses a SIGPROF timer using the setitimer interface. Why
> > is it HZ dependent?
>
> Even though you get a signal you have to calculate the elapsed time.
> The profiling codes prefers "times" to "getrusage" to "clock."
>
> Unfortunately to interpret "times" information you need to multiply by
> ticks_to_msec.
>
> IMO any interface exporting/using ticks is broken. Accurate time can
> be provided through other interfaces. Userspace should never see ticks,
> only converted time.
userspace should see converted ticks. ie divide by 10 if CONFIG_HZ is 1000
since PA userspace expects to see 100Hz.
--
"Next the statesmen will invent cheap lies, putting the blame upon
the nation that is attacked, and every man will be glad of those
conscience-soothing falsities, and will diligently study them, and refuse
to examine any refutations of them; and thus he will by and by convince
himself that the war is just, and will thank God for the better sleep
he enjoys after this process of grotesque self-deception." -- Mark Twain
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [parisc-linux] [Testers wanted] New glibc with profiling fixed.
2005-07-26 14:25 ` Randolph Chung
@ 2005-07-26 17:01 ` Carlos O'Donell
2005-07-26 17:09 ` Matthew Wilcox
0 siblings, 1 reply; 33+ messages in thread
From: Carlos O'Donell @ 2005-07-26 17:01 UTC (permalink / raw)
To: Randolph Chung; +Cc: Tres Melton, parisc-linux, Matthew Wilcox
On Tue, Jul 26, 2005 at 10:25:44PM +0800, Randolph Chung wrote:
> >User space should not "know" what HZ the kernel is using. Instead, all
> >interfaces should be properly reported in terms of whatever HZ userspace
> >used to assume (100 on i386, other values on other platforms). I don't
> >know what interface gprof is using, but it needs to be fixed.
>
> I thought gprof uses a SIGPROF timer using the setitimer interface. Why
> is it HZ dependent?
Even though you get a signal you have to calculate the elapsed time.
The profiling codes prefers "times" to "getrusage" to "clock."
Unfortunately to interpret "times" information you need to multiply by
ticks_to_msec.
IMO any interface exporting/using ticks is broken. Accurate time can
be provided through other interfaces. Userspace should never see ticks,
only converted time.
c.
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [parisc-linux] [Testers wanted] New glibc with profiling fixed.
2005-07-26 14:18 ` Matthew Wilcox
2005-07-26 14:25 ` Randolph Chung
@ 2005-07-26 15:26 ` Tres Melton
2005-07-26 17:16 ` Carlos O'Donell
2 siblings, 0 replies; 33+ messages in thread
From: Tres Melton @ 2005-07-26 15:26 UTC (permalink / raw)
To: Matthew Wilcox; +Cc: parisc-linux
On Tue, 2005-07-26 at 15:18 +0100, Matthew Wilcox wrote:
> On Tue, Jul 26, 2005 at 07:37:16AM -0600, Tres Melton wrote:
> > I'm advocating a way for user space to *know* what the kernel is
> > running. It is this thinking crap that is messing things up.
>
> User space should not "know" what HZ the kernel is using. Instead, all
> interfaces should be properly reported in terms of whatever HZ userspace
> used to assume (100 on i386, other values on other platforms). I don't
> know what interface gprof is using, but it needs to be fixed.
I disagree as do others but many agree with you. The issue will soon be
brought to the LKML so you can discuss it there later this week. It is
not gprof that is messing up it is gcc/glibc. When a program is
compiled with the "-pg" options it emits a gmon.out file when run and
that file has bad data that gprof is trusting.
> Otherwise we stand no chance of going to a dynamic HZ in the future.
When you say, dynamic tick are you referring to things like speed step
and power now things or just changing the kernel's internal frequency on
the fly?
--
Tres
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [parisc-linux] [Testers wanted] New glibc with profiling fixed.
2005-07-26 14:18 ` Matthew Wilcox
@ 2005-07-26 14:25 ` Randolph Chung
2005-07-26 17:01 ` Carlos O'Donell
2005-07-26 15:26 ` Tres Melton
2005-07-26 17:16 ` Carlos O'Donell
2 siblings, 1 reply; 33+ messages in thread
From: Randolph Chung @ 2005-07-26 14:25 UTC (permalink / raw)
To: Matthew Wilcox; +Cc: Tres Melton, parisc-linux
> User space should not "know" what HZ the kernel is using. Instead, all
> interfaces should be properly reported in terms of whatever HZ userspace
> used to assume (100 on i386, other values on other platforms). I don't
> know what interface gprof is using, but it needs to be fixed.
I thought gprof uses a SIGPROF timer using the setitimer interface. Why
is it HZ dependent?
randolph
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [parisc-linux] [Testers wanted] New glibc with profiling fixed.
2005-07-26 13:37 ` Tres Melton
@ 2005-07-26 14:18 ` Matthew Wilcox
2005-07-26 14:25 ` Randolph Chung
` (2 more replies)
0 siblings, 3 replies; 33+ messages in thread
From: Matthew Wilcox @ 2005-07-26 14:18 UTC (permalink / raw)
To: Tres Melton; +Cc: parisc-linux
On Tue, Jul 26, 2005 at 07:37:16AM -0600, Tres Melton wrote:
> I'm advocating a way for user space to *know* what the kernel is
> running. It is this thinking crap that is messing things up.
User space should not "know" what HZ the kernel is using. Instead, all
interfaces should be properly reported in terms of whatever HZ userspace
used to assume (100 on i386, other values on other platforms). I don't
know what interface gprof is using, but it needs to be fixed.
Otherwise we stand no chance of going to a dynamic HZ in the future.
--
"Next the statesmen will invent cheap lies, putting the blame upon
the nation that is attacked, and every man will be glad of those
conscience-soothing falsities, and will diligently study them, and refuse
to examine any refutations of them; and thus he will by and by convince
himself that the war is just, and will thank God for the better sleep
he enjoys after this process of grotesque self-deception." -- Mark Twain
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [parisc-linux] [Testers wanted] New glibc with profiling fixed.
2005-07-26 13:24 ` Grant Grundler
@ 2005-07-26 13:37 ` Tres Melton
2005-07-26 14:18 ` Matthew Wilcox
0 siblings, 1 reply; 33+ messages in thread
From: Tres Melton @ 2005-07-26 13:37 UTC (permalink / raw)
To: Grant Grundler; +Cc: parisc-linux
On Tue, 2005-07-26 at 07:24 -0600, Grant Grundler wrote:
> I can do that in August...thanks for pointing that out.
> I read the first parts of the report but don't recall seeing
> the kernel patch.
http://bugs.gentoo.org/show_bug.cgi?id=90090#c21
It is not a patch file just in the comment.
> Right. That's why jiffies exported to user space has to be "normalized"
> for whatever rate user space *thinks* the kernel is running.
I'm advocating a way for user space to *know* what the kernel is
running. It is this thinking crap that is messing things up.
> > You spoke of another kernel
> > dev, could you ask him if he is opposed to exporting the correct value
> > in the elf header (or /proc) and to give a quick justification for his
> > response, pro or con. Thanks.
>
> He's already flown back to germany and it was just incidental that
> he was available. I'd rather not pester him about this since it
> seems to be a fairly well understood issue...at least to some people.
If you happen to speak to him again I would still like any extra info.
Don't bother him explicitly for this though. The issue will be taken to
the LKML by the end of the week.
> thanks,
> grant
--
Tres
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [parisc-linux] [Testers wanted] New glibc with profiling fixed.
[not found] ` <1122272788.10644.71.camel@thor.tres.org>
@ 2005-07-26 13:24 ` Grant Grundler
2005-07-26 13:37 ` Tres Melton
0 siblings, 1 reply; 33+ messages in thread
From: Grant Grundler @ 2005-07-26 13:24 UTC (permalink / raw)
To: Tres Melton; +Cc: parisc-linux
Tres,
please keep this conversation on the parisc-linux mailing list.
I've added them back into the CC list.
On Mon, Jul 25, 2005 at 12:26:28AM -0600, Tres Melton wrote:
> > I'm happy to run more tests on kernel patches if that would help.
>
> There is a patch to the kernel in the above bug report that makes Linux
> put the right value in the elf header. That is going to be one of the
> proposed patches. I've been running a patched kernel for about a week
> with no noticeable side effects. If you would like you could try that
> and note any breakage in user space.
I can do that in August...thanks for pointing that out.
I read the first parts of the report but don't recall seeing
the kernel patch.
> When you said 'conversation' did you mean 'conversion'?
Yes - thanks for catching that.
> If so, there is no way for gprof to due that
> conversion without knowing what the conversion rate is. The HZ is now
> set at compile time, as of 2.6.13-rc3, and the conversion rate to
> USER_HZ is not available to user space.
Right. That's why jiffies exported to user space has to be "normalized"
for whatever rate user space *thinks* the kernel is running.
> You spoke of another kernel
> dev, could you ask him if he is opposed to exporting the correct value
> in the elf header (or /proc) and to give a quick justification for his
> response, pro or con. Thanks.
He's already flown back to germany and it was just incidental that
he was available. I'd rather not pester him about this since it
seems to be a fairly well understood issue...at least to some people.
thanks,
grant
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [parisc-linux] [Testers wanted] New glibc with profiling fixed.
2005-07-22 12:56 Tres Melton
@ 2005-07-25 0:09 ` Grant Grundler
[not found] ` <1122272788.10644.71.camel@thor.tres.org>
0 siblings, 1 reply; 33+ messages in thread
From: Grant Grundler @ 2005-07-25 0:09 UTC (permalink / raw)
To: Tres Melton; +Cc: parisc-linux
On Fri, Jul 22, 2005 at 06:56:34AM -0600, Tres Melton wrote:
> | Here's "apps/openssl speed rsa" gprof output from my c3000.
> | (2.6.0-pa7, Debian testing)
> |
> | TBH, it looks wrong.
>
> It is wrong. For details please see:
>
> http://bugs.gentoo.org/show_bug.cgi?id=90090
Ugh. user space vs kernel space HZ battles.
> If you have any more information on the subject
Sorry - I really don't.
I'm happy to run more tests on kernel patches if that would help.
> I would appreciate it
> as a number of us are preparing to take this issue to the LKML. I'm
> specifically looking at a convincing reason to put forth to Linus to
> export the correct clock-ticks/second. Linus has stated in the past
> that user space has no need for the information. A couple of other
> kernel devs are going to back me up here but we need a good argument to
> get Linus to change his mind.
I'm certainly not the one who has a solid grasp of the problem.
I just recognized the output looked wrong.
Another kernel developer has suggested this is a gprof bug.
I was told the kernel has two types of ticks: one for kernel and another
for users space - some conversation needs to take place by gprof
that I know nothing about.
thanks,
grant
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
^ permalink raw reply [flat|nested] 33+ messages in thread
* [parisc-linux] [Testers wanted] New glibc with profiling fixed.
@ 2005-07-22 12:56 Tres Melton
2005-07-25 0:09 ` Grant Grundler
0 siblings, 1 reply; 33+ messages in thread
From: Tres Melton @ 2005-07-22 12:56 UTC (permalink / raw)
To: parisc-linux
Grant,
While searching the web I came across your email:
http://lists.parisc-linux.org/pipermail/parisc-linux/2004-January/022125.html
where you said:
Here's "apps/openssl speed rsa" gprof output from my c3000.
(2.6.0-pa7, Debian testing)
TBH, it looks wrong.
It is wrong. For details please see:
http://bugs.gentoo.org/show_bug.cgi?id=90090
If you have any more information on the subject I would appreciate it
as a number of us are preparing to take this issue to the LKML. I'm
specifically looking at a convincing reason to put forth to Linus to
export the correct clock-ticks/second. Linus has stated in the past
that user space has no need for the information. A couple of other
kernel devs are going to back me up here but we need a good argument to
get Linus to change his mind.
Thanks,
--
Tres
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [parisc-linux] [Testers wanted] New glibc with profiling fixed.
[not found] <no.id>
2004-01-07 21:14 ` John David Anglin
@ 2004-01-07 21:14 ` John David Anglin
1 sibling, 0 replies; 33+ messages in thread
From: John David Anglin @ 2004-01-07 21:14 UTC (permalink / raw)
To: John David Anglin; +Cc: carlos, parisc-linux, debian-hppa
> Did I miss something?
Yup.
Dave
--
J. David Anglin dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6602)
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [parisc-linux] [Testers wanted] New glibc with profiling fixed.
[not found] <no.id>
@ 2004-01-07 21:14 ` John David Anglin
2004-01-07 21:14 ` John David Anglin
1 sibling, 0 replies; 33+ messages in thread
From: John David Anglin @ 2004-01-07 21:14 UTC (permalink / raw)
To: John David Anglin; +Cc: carlos, parisc-linux, debian-hppa
> Did I miss something?
Yup.
Dave
--
J. David Anglin dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6602)
^ permalink raw reply [flat|nested] 33+ messages in thread
* [parisc-linux] [Testers wanted] New glibc with profiling fixed.
@ 2004-01-05 19:48 Carlos O'Donell
0 siblings, 0 replies; 33+ messages in thread
From: Carlos O'Donell @ 2004-01-05 19:48 UTC (permalink / raw)
To: parisc-linux, debian-hppa
pa'ers,
glibc 2.3.2.ds1-10
- Added profiling patches (Thanks Randolph!)
- Rebuilt glibc.
- Did not modify changelog or bump version.
Testers wanted please, in particular to test if building with -pg works
on your system and you get the expected results.
If testing goes well, these patches are going into debian-glibc's tree.
Cheers,
Carlos.
^ permalink raw reply [flat|nested] 33+ messages in thread
end of thread, other threads:[~2005-07-26 18:08 UTC | newest]
Thread overview: 33+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-01-05 19:48 [parisc-linux] [Testers wanted] New glibc with profiling fixed Carlos O'Donell
2004-01-05 19:48 ` Carlos O'Donell
2004-01-11 4:09 ` Grant Grundler
2004-01-11 20:43 ` Carlos O'Donell
2004-01-11 20:43 ` Carlos O'Donell
2004-01-12 16:38 ` Grant Grundler
2004-01-12 16:38 ` Grant Grundler
2004-01-13 5:42 ` Grant Grundler
2004-01-13 5:42 ` Grant Grundler
2004-01-13 8:46 ` Joel Soete
2004-01-13 8:46 ` Joel Soete
2004-01-11 4:09 ` Grant Grundler
2004-01-05 19:48 ` Carlos O'Donell
2004-01-05 20:45 ` Grant Grundler
2004-01-05 22:00 ` Carlos O'Donell
2004-01-05 22:00 ` Carlos O'Donell
2004-01-05 20:45 ` Grant Grundler
2004-01-07 21:04 ` John David Anglin
2004-01-07 21:04 ` John David Anglin
2004-01-05 19:48 Carlos O'Donell
[not found] <no.id>
2004-01-07 21:14 ` John David Anglin
2004-01-07 21:14 ` John David Anglin
2005-07-22 12:56 Tres Melton
2005-07-25 0:09 ` Grant Grundler
[not found] ` <1122272788.10644.71.camel@thor.tres.org>
2005-07-26 13:24 ` Grant Grundler
2005-07-26 13:37 ` Tres Melton
2005-07-26 14:18 ` Matthew Wilcox
2005-07-26 14:25 ` Randolph Chung
2005-07-26 17:01 ` Carlos O'Donell
2005-07-26 17:09 ` Matthew Wilcox
2005-07-26 18:08 ` Carlos O'Donell
2005-07-26 15:26 ` Tres Melton
2005-07-26 17:16 ` Carlos O'Donell
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.