All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@zip.com.au>
To: Lincoln Dale <ltd@cisco.com>
Cc: Benjamin LaHaise <bcrl@redhat.com>,
	Andrea Arcangeli <andrea@suse.de>,
	"Stephen C. Tweedie" <sct@redhat.com>,
	Linus Torvalds <torvalds@transmeta.com>,
	Steve Lord <lord@sgi.com>,
	linux-kernel@vger.kernel.org
Subject: Re: ext2 performance in 2.5.25 versus 2.4.19pre8aa2
Date: Sun, 14 Jul 2002 23:52:25 -0700	[thread overview]
Message-ID: <3D327129.691A95AF@zip.com.au> (raw)
In-Reply-To: 5.1.0.14.2.20020715160245.02ad0978@mira-sjcm-3.cisco.com

Lincoln Dale wrote:
> 
> At 10:30 PM 14/07/2002 -0700, Andrew Morton wrote:
> >Funny thing about your results is the presence of sched_yield(),
> >especially in the copy-from-pagecache-only load.  That test should
> >peg the CPU at 100% and definitely shouldn't be spending time in
> >default_idle.  So who is calling sched_yield()?  I think it has to be
> >your test app?
> >
> >Be aware that the sched_yield() behaviour in 2.5 has changed a lot
> >wrt 2.4.  It has made StarOffice 5.2 completely unusable on a non-idle
> >system, for a start.  (This is a SO problem and not a kernel problem,
> >but it's a lesson).
> 
> my test app uses pthreads (one thread per disk-worker) and
> pthread_cond_wait in the master task to wait for all workers to finish.
> i'll switch the app to use clone() and sys_futex instead.

OK.

> i guess in that case, its debatable whether its a kernel problem or not --
> pthreads is out there, and if its default behavior is bad, any threaded app
> which uses it will also be bad.

Well if your machine is executing a single cycle in default_idle
with that load then there's a bug somewhere.

I took a quick look at glibc-linuxthreads but as usual, my brain
turned to mush and it took seven years off my life.

If you can send me a copy of your test app I'll take a look
at what's going on.

Thanks.

  reply	other threads:[~2002-07-15  6:42 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-07-08  3:19 direct-to-BIO for O_DIRECT Andrew Morton
2002-07-08  3:30 ` Lincoln Dale
2002-07-08  7:44 ` Ingo Oeser
2002-07-11  2:25 ` Lincoln Dale
2002-07-11  3:24   ` Andrew Morton
2002-07-11  3:25     ` Lincoln Dale
     [not found]       ` <3D2CFF48.9EFF9C59@zip.com.au>
2002-07-14 12:22         ` ext2 performance in 2.5.25 versus 2.4.19pre8aa2 Lincoln Dale
2002-07-15  5:30           ` Andrew Morton
2002-07-15  6:06             ` Lincoln Dale
2002-07-15  6:52               ` Andrew Morton [this message]
2002-07-15  9:49               ` Andrea Arcangeli
2002-07-15 10:16                 ` Lincoln Dale
2002-07-15 18:08                 ` Andrew Morton
2002-07-17 19:22             ` Daniel Phillips
2002-07-15 16:30           ` Benjamin LaHaise
2002-07-11 19:52   ` direct-to-BIO for O_DIRECT Jesse Barnes
2002-07-11 23:40     ` Lincoln Dale

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=3D327129.691A95AF@zip.com.au \
    --to=akpm@zip.com.au \
    --cc=andrea@suse.de \
    --cc=bcrl@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lord@sgi.com \
    --cc=ltd@cisco.com \
    --cc=sct@redhat.com \
    --cc=torvalds@transmeta.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 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.