2011/12/30 Jérémie Koenig
> On Thu, Dec 29, 2011 at 1:25 AM, Samuel Thibault
> wrote:
> > [...], but I believe it's still a bit revealing: I had already noticed
> > that ext2fs spends most of its time in the kernel (like 90%), and it
> > here seems we're spending a lot of time just managing the
Jérémie Koenig, le Fri 30 Dec 2011 12:46:39 +0100, a écrit :
> On Thu, Dec 29, 2011 at 1:25 AM, Samuel Thibault
> wrote:
> > [...], but I believe it's still a bit revealing: I had already noticed
> > that ext2fs spends most of its time in the kernel (like 90%), and it
> > here seems we're spending
On Thu, Dec 29, 2011 at 1:25 AM, Samuel Thibault
wrote:
> [...], but I believe it's still a bit revealing: I had already noticed
> that ext2fs spends most of its time in the kernel (like 90%), and it
> here seems we're spending a lot of time just managing the ext2fs thread
> sleeps (no, there aren
Samuel Thibault, le Thu 29 Dec 2011 01:25:36 +0100, a écrit :
> It might be biaised by the clock not being able to tick everywhere in
> the kernel (though I guess e.g. most of the IPC machinery is running at
> ipl0?),
But the linux drivers do get an opportunity to run their bottom halves
etc. when
El Thu, 29 Dec 2011 01:25:36 +0100
Samuel Thibault escribió:
> It might be biaised by the clock not being able to tick everywhere in
> the kernel (though I guess e.g. most of the IPC machinery is running
> at ipl0?), but I believe it's still a bit revealing: I had already
> noticed that ext2fs sp
Svante Signell, le Thu 29 Dec 2011 11:05:20 +0100, a écrit :
> On Thu, 2011-12-29 at 01:25 +0100, Samuel Thibault wrote:
> > I've done some stat-based kernel profiling (I'll have to post how to do
> > it on the wiki sometime) on ext2fs doing nothing more than
> >
On Thu, 2011-12-29 at 01:25 +0100, Samuel Thibault wrote:
> Hello,
>
> I've done some stat-based kernel profiling (I'll have to post how to do
> it on the wiki sometime) on ext2fs doing nothing more than
>
> while true; do rm -f blop ; \cp -f blip blop ; done
> I
Hello,
I've done some stat-based kernel profiling (I'll have to post how to do
it on the wiki sometime) on ext2fs doing nothing more than
while true; do rm -f blop ; \cp -f blip blop ; done
(the file is 2MiB)
The results are:
thread_will_wait: 11.70%
thread_go:
Hi,
Michael Casadevall, le Fri 03 Aug 2007 21:46:54 -0400, a écrit :
> The first thing you'll notice is a distinct lack of times.
Times are in seconds. So you need to do something that takes more than a
cent of second to actually see anything, e.g. untar gcc.tgz.
Samuel
___
. Here is an fixed patch.
Samuel
#! /bin/sh -e
# DP: Fix profiling on hurd-i386.
dir=
if [ $# -eq 3 -a "$2" = '-d' ]; then
pdir="-d $3"
dir="$3/"
elif [ $# -ne 1 ]; then
echo >&2 "`basename $0`: script expects -patch|-unpatch as argume
reopen 433539
thanks
Hello!
On Sat, Jul 14, 2007 at 10:49:13AM -0400, Michael Casadevall wrote:
> After some trail and error as well as reading up how static binaries work
> and the difference between gcrt0 and gcrt1, I was able to fix the profiling
> bug with a GCC spec file:
Are
After some trail and error as well as reading up how static binaries work and
the difference between gcrt0 and gcrt1, I was able to fix the profiling bug
with a GCC spec file:
%rename startfile old_startfile
*startfile: %{!shared: %{!static: %{pg:gcrt0.o%s} %{!pg:%{p:gcrt0.o%s}
%{!p:crt1.o%s
Is it know that profiling is currently broken? This is because gcrt1.o
uses the dynamic version of start.S instead of the Hurd-borked static
version of start.S. It's probably just a matter of fixing blackmagic in
glibc/csu/Makefile.
Samuel
__
> There was only one istance of the profile-enable ext2 translator. The
> problem is the same using gcc 2.95 and gcc-3.0. I think that probably for
> some reason after sending the reply to fsys_goway the task is forced to die.
That should not be the case. Can you please figure out what happens h
On Tue, Jan 01, 2002 at 03:15:45PM +0100, Niels Möller wrote:
> I think the writing of profiling information on process exit is
> supposed accumulate information if you're running more than one
> instance of the profiled program.
There was only one istance of the profile-enable e
Diego Roversi <[EMAIL PROTECTED]> writes:
> Probably the rename is not strictly necessary, btw before running gprof,
> remember to rename back gmon.out to gmon.out. The _mcleanup() forces the
> process to produce the gmon.out file.
I think the writing of profiling information on
Hello,
finally I succeded in profiling the ext2fs translator and I found the most
of the time is spent waiting for a lock.
Here the result of profiling a gnumach compile:
Flat profile:
Each sample counts as 0.0001 seconds.
% cumulative self self total
time
rea is used for about 10-15 MB. So the vm subsystem is working
reasonably well. Instead the ext2fs translator is eating a lot of cpu power
(note: I have quite fast cpu, duron 950 Mhz). One reason can be the high
number of thread, that is more than four hundred.
So I tried to compile with profili
Roland McGrath <[EMAIL PROTECTED]> writes:
> In general, what's most useful to profile are real programs running real
> workloads to see what spots actually matter in practice. Profiling
> targetted benchmarks (like the fork tester) mostly just confirms the
> spots of sl
t; * What parts of the Hurd are good candidates for profiling? Thomas' fork
> test. File system operations. Servers.
In general, what's most useful to profile are real programs running real
workloads to see what spots actually matter in practice. Profiling
targetted benchmarks (like
On Mon, May 14, 2001 at 07:36:23PM -0400, Roland McGrath wrote:
> > The specs file implement the following option combinations:
> > Notes: -shared overrides (and prevents) profiling options.
> >-profile forces to link the profiling C library statically
> >
On Mon, May 14, 2001 at 06:20:50PM -0400, Roland McGrath wrote:
> Well, I'm not quite sure how to react to this. I'm not exactly surprised
> that there is a problem. Frankly, I'm somewhat surprised that profiling
> actually does work at all, and I'm having a hard
> The specs file implement the following option combinations:
> Notes: -shared overrides (and prevents) profiling options.
>-profile forces to link the profiling C library statically
>-pg/-p does link to the normal C library (dynamically or statically)
Is this the s
the program and the C library:
$ gcc -o main main.c -profile
$ ./main
$ gprof main gmon.out
The specs file implement the following option combinations:
Notes: -shared overrides (and prevents) profiling options.
-profile forces to link the profiling C library statically
-pg/-p does link
Well, I'm not quite sure how to react to this. I'm not exactly surprised
that there is a problem. Frankly, I'm somewhat surprised that profiling
actually does work at all, and I'm having a hard time taking this bug
report as anything but good news. :-)
> However, we don&
On Mon, May 14, 2001 at 11:39:28PM +0200, Marcus Brinkmann wrote:
> Now the crux. When using -lc, we use shared linking, and gcrt1.o, which
> works. When using -lc_p, we *should* use something like crt0.o, but which
> starts the profiler. Let's call it gcrt0.o.
>
> Unfortunately, such a thing
start, but
> the address was teh symbol address in objdump --syms output + 2).
>
> When I modify the linking stage to link with -lc rather than -lc_p, I get a
> dynamically linked executable which works. The gmon.out output can be used
> with gprof.
I think I have identified the prob
task_get_sampled_pcs failing). Any non-trivial program
works correctly.
So, there is some issue with the profiling C lib and static libs.
Marcus
--
`Rhubarb is no Egyptian god.' Debian http://www.debian.org [EMAIL PROTECTED]
Marcus Brinkmann GNUhttp://www.gnu.org
28 matches
Mail list logo
