public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Heinz Diehl <htd@fancy-poultry.org>
To: linux-kernel@vger.kernel.org
Subject: Re: [ANNOUNCE] BFS CPU scheduler version 0.420 AKA "Smoking" for linux kernel 3.3.0
Date: Wed, 28 Mar 2012 07:12:43 +0200	[thread overview]
Message-ID: <20120328051243.GA2138@fancy-poultry.org> (raw)
In-Reply-To: <57375.1332641134@turing-police.cc.vt.edu>

On 25.03.2012, Valdis.Kletnieks@vt.edu wrote: 

> I'va always wondered what people are using to measure interactivity. Do we have
> some hard numbers from scheduler traces, or is it a "feels faster"?

I guess it's a "feels faster", because it's the only thing that
counts. Given that there is strong evidence that scheduler A is
"faster, more interactive", whatever... than scheduler B, but a
controlled trial shows a significantly better "feels faster"
experience using scheduler B, I'm quite shure that people would choose
scheduler B over A, and that's quite ok. It does what they expect it
to do, despite evidence which documents the opposite.
 

> And if  it's a subjective thing, how are people avoiding confirmation bias (where you
> decide it feels faster because it's the new kernel and *should* feel faster)?

Confirmation bias is one thing, and it does exist. Surely. So it's up
to the user if it wants evidence, or if it's enough that it feels
faster. I guess that evidence doesn't really matter for the most of
the users as long as they have a positive experience.

> Anybody doing blinded boots, where a random kernel old/new is booted and the
> user grades the performance without knowing which one was actually running?

Hey, we could construct a randomized controlled trial on this :-)
 
> And yes, this can be a real issue - anybody who's been a aysadmin for
> a while will have at least one story of scheduling an upgrade, scratching it
> at the last minute, and then having users complain about how the upgrade
> ruined performance and introduced bugs...

Yep. They who have to do "real work" will rather base it on evidence
than trust their own feelings.

 



  parent reply	other threads:[~2012-03-28  5:12 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-24  9:39 [ANNOUNCE] BFS CPU scheduler version 0.420 AKA "Smoking" for linux kernel 3.3.0 Con Kolivas
2012-03-24  9:53 ` Gene Heskett
2012-03-24 10:00   ` Con Kolivas
2012-03-25  2:05   ` Valdis.Kletnieks
2012-03-25  2:33     ` Con Kolivas
2012-03-25 13:37     ` Mike Galbraith
2012-03-26 22:30       ` Con Kolivas
2012-03-27  5:13         ` Mike Galbraith
     [not found]       ` <CABqErrGaBLisO4YK5dP2O9Pv0QonZ+q9G43jm=Nf12yWVG,<1332825236.7411.54.camel@marge.simpson.net>
     [not found]         ` <SNT112-W24CBD78928F4DD6AFDA564A14A0@phx.gbl>
2012-03-28  3:48           ` Mike Galbraith
2012-03-28  5:12     ` Heinz Diehl [this message]
2012-03-28 12:39       ` Nikos Chantziaras
2012-03-28 13:53         ` Heinz Diehl
2012-03-28 15:28           ` Nikos Chantziaras
2012-03-28 16:44         ` Mike Galbraith
  -- strict thread matches above, loose matches on Subject: below --
2012-03-27 20:17 Mike Blue
2012-03-27 20:45 ` Pekka Enberg
2012-03-27 20:52 Micheal Blue
     [not found] <iIvLH-3cI-5@gated-at.bofh.it>
     [not found] ` <iIw53-3TH-15@gated-at.bofh.it>
     [not found]   ` <iIL45-3H1-5@gated-at.bofh.it>
     [not found]     ` <iJTsB-44L-1@gated-at.bofh.it>
2012-03-28 19:39       ` Martin Rogge

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=20120328051243.GA2138@fancy-poultry.org \
    --to=htd@fancy-poultry.org \
    --cc=linux-kernel@vger.kernel.org \
    /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