All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <jens.axboe@oracle.com>
To: Ingo Molnar <mingo@elte.hu>
Cc: Frans Pop <elendil@planet.nl>,
	linux-kernel@vger.kernel.org,
	Peter Zijlstra <a.p.zijlstra@chello.nl>
Subject: Re: [long] Another BFS versus CFS shakedown
Date: Fri, 11 Sep 2009 09:58:32 +0200	[thread overview]
Message-ID: <20090911075832.GG18599@kernel.dk> (raw)
In-Reply-To: <20090911075331.GA14489@elte.hu>

On Fri, Sep 11 2009, Ingo Molnar wrote:
> 
> * Jens Axboe <jens.axboe@oracle.com> wrote:
> 
> > On Fri, Sep 11 2009, Frans Pop wrote:
> > > On Friday 11 September 2009, Ingo Molnar wrote:
> > > > Note, the one you used was a still buggy version of latt.c producing
> > > > bogus latency numbers - you will need the fix to it attached below.
> > > 
> > > Yes, I'm aware of that and have already copied Jens' latest version.
> > 
> > BTW, I put it in a git repo, it quickly gets really confusing with so
> > many version going around. So that can be accessed here:
> > 
> > git://git.kernel.dk/latt.git
> > 
> > and as with my other repos, snapshots are automatically generated every
> > hour when new commits have been made. To get the very latest latt and
> > not have to use git, download:
> > 
> > http://brick.kernel.dk/snaps/latt-git-latest.tar.gz
> 
> Btw., your earlier latt reports should be discarded as invalid due 
> to that bug.

Yes

> With the fixed latt.c version the mainline latencies (both 
> worst-case and average) were reported to be better after the poll() 
> bug got fixed, so in that area, for this kind of measurement, 
> mainline seems to be working well.
> 
> [ What happened is that the poll() bug was creating false latencies
>   in the mainline scheduler tests. (BFS avoided measuring that bug
>   incidentally, by its agressive balancer moved the wakee tasks away
>   from the buggy busy-looping poll() looping parent task. Two
>   instances of latt.c would possibly have shown similar latencies.) ]
> 
> I see you added new 'work generator' changes to latt.c now, will 
> check/validate that version of latt.c too.

I did, it's a simple 'generate random data and compress it' work piece
for each client. You can control the amount of work with -x, which sets
the kb of data it'll work on. Stats are generated both for wakeup
latency, and work processing latency.

-- 
Jens Axboe


      reply	other threads:[~2009-09-11  7:58 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-08 23:42 [long] Another BFS versus CFS shakedown Frans Pop
2009-09-09  0:01 ` Nikos Chantziaras
2009-09-09  0:44 ` Frans Pop
2009-09-11  6:20 ` Ingo Molnar
2009-09-11  7:04   ` Frans Pop
2009-09-11  7:17     ` Jens Axboe
2009-09-11  7:53       ` Ingo Molnar
2009-09-11  7:58         ` Jens Axboe [this message]

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=20090911075832.GG18599@kernel.dk \
    --to=jens.axboe@oracle.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=elendil@planet.nl \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    /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.