public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andrew Theurer <habanero@us.ibm.com>
To: Andi Kleen <ak@suse.de>
Cc: Emmanuel Varagnat <Emmanuel_Varagnat-AEV010@email.mot.com>,
	Hans Reiser <reiser@namesys.com>,
	linux-kernel@vger.kernel.org
Subject: Re: Journal Filesystem Comparison on Netbench
Date: Tue, 28 Aug 2001 10:07:38 -0500	[thread overview]
Message-ID: <3B8BB3BA.7FBC8EE4@us.ibm.com> (raw)
In-Reply-To: <3B8A6122.3C784F2D@us.ibm.com.suse.lists.linux.kernel> <3B8AA7B9.8EB836FF@namesys.com.suse.lists.linux.kernel> <oupsneck77v.fsf@pigdrop.muc.suse.de> <3B8B755F.D6317A9A@crm.mot.com> <20010828125003.A27996@gruyere.muc.suse.de>

Andi Kleen wrote:
> 
> On Tue, Aug 28, 2001 at 12:41:35PM +0200, Emmanuel Varagnat wrote:
> >
> > Andi Kleen wrote:
> > >
> > > It does not really look like a locking problem. If you look at the profiling
> > > logs it is pretty clear that the problem is the algorithm used in
> > > bitmap.c:find_forward. find_forward and reiserfs_in_journal
> > > ...
> > > journaled blocks set also, to quickly skip them for the common case.
> >
> > I'm very interested in the way you did profiling.
> > Did you compile the kernel with profiling options (gprof ?) ?
> > If so, where the profiling information file is saved ?
> 
> I did not do any profiling in this case; I just read an existing log.
> If you want to do profiling yourself you could use the simple
> builtin statistical profiler: boot with profile=2 on the command line
> and read the log at anytime using the readprofile command.
> Other ways are documented on the lse homepage http://lse.sourceforge.net

The profiles I provided were with SGI's kernprof 0.9.2.  I chose ACG,
which does have a lot of overhead (cg_record_arc and mcount), but also
provides a lot of information.  I have a separate kernel for each
filesystem and each filesystem+profle_patch (10 kernels).  No modules
were used so that all profiles have no 'unknown kernel' functions.  Each
profile was taken for 60 seconds, starting at 90 seconds into the test. 
All profiles were taken on the 44 client test.  

Andrew Theurer

  parent reply	other threads:[~2001-08-28 15:08 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <3B8A6122.3C784F2D@us.ibm.com.suse.lists.linux.kernel>
     [not found] ` <3B8AA7B9.8EB836FF@namesys.com.suse.lists.linux.kernel>
2001-08-28  6:51   ` Journal Filesystem Comparison on Netbench Andi Kleen
2001-08-28 10:41     ` Emmanuel Varagnat
2001-08-28 10:50       ` Andi Kleen
2001-08-28 11:35         ` Emmanuel Varagnat
2001-08-28 15:07         ` Andrew Theurer [this message]
2001-08-27 15:02 Andrew Theurer
2001-08-27 20:04 ` Hans Reiser
2001-08-27 20:29   ` Andrew Theurer
2001-08-27 21:19   ` Randy.Dunlap
2001-08-28 10:05 ` Roberto Nibali
2001-08-28 15:28   ` Andrew Theurer
2001-08-28 18:38     ` Andrew Morton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3B8BB3BA.7FBC8EE4@us.ibm.com \
    --to=habanero@us.ibm.com \
    --cc=Emmanuel_Varagnat-AEV010@email.mot.com \
    --cc=ak@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=reiser@namesys.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox