linux-kernel - Re: [ANNOUNCE] BFS CPU scheduler version 0.420 AKA "Smoking" for linux kernel 3.3.0

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20120328051243.GA2138@fancy-poultry.org>
Date:	Wed, 28 Mar 2012 07:12:43 +0200
From:	Heinz Diehl <htd@...cy-poultry.org>
To:	linux-kernel@...r.kernel.org
Subject: Re: [ANNOUNCE] BFS CPU scheduler version 0.420 AKA "Smoking" for
 linux kernel 3.3.0

On 25.03.2012, Valdis.Kletnieks@...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.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/