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: <b21f8390707312319l3ffd8e7cn85984e32344a41f2@mail.gmail.com>
Date:	Wed, 1 Aug 2007 16:19:36 +1000
From:	"Matthew Hawkins" <darthmdh@...il.com>
To:	"Adrian Bunk" <bunk@...sta.de>
Cc:	"Roland Dreier" <rdreier@...co.com>,
	"Christoph Hellwig" <hch@...radead.org>,
	"Jacob Braun" <jwbraun@...il.com>,
	kriko <kristjan.ugrin@...il.com>, ck@....kolivas.org,
	"Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>,
	linux-mm@...ck.org, "Martin Schwidefsky" <schwidefsky@...ibm.com>
Subject: Re: [ck] Re: SD still better than CFS for 3d ?

On 8/1/07, Adrian Bunk <bunk@...sta.de> wrote:
> But there's not much value in benchmarking if an important part of the
> performance critical code is in some undebuggable driver...

In this case we don't care about the performance of the video driver.
This isn't a race to see who can get the most fps.  The driver can be
thought of as a black box so long as comparative benchmarks are done
with the same driver.

What we're looking for primarily is progress or regress in
interactivity under load with different cpu schedulers, and secondly
the effect of swap prefetch.  The video driver is irrelevant -
especially considering the people doing this testing have a wide
variety of video cards.  This is why I have included some commentary
on "feel" because that's the important part.

Ingo specifically asked for CFS v20 in 2.6.23 to be included in the
testing (its not available separately on his website), hence the need
to be able to bring up one's usual working environment under that
kernel also so the results aren't skewed by driver artifacts.

For my next trick, I'll attempt to quantify the "feel" bits using
scheduler statistics.
While riding a unicycle.

Okay, scratch the unicycle ;-)

-- 
Matt
-
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ