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: <b21f8390707310914p435c8b06r878db20f6803cdc6@mail.gmail.com>
Date:	Wed, 1 Aug 2007 02:14:55 +1000
From:	"Matthew Hawkins" <darthmdh@...il.com>
To:	"Ingo Molnar" <mingo@...e.hu>
Cc:	"Kenneth Prugh" <ken69267@...il.com>, ck@....kolivas.org,
	"Linus Torvalds" <torvalds@...ux-foundation.org>,
	"Kasper Sandberg" <lkml@...anurb.dk>,
	"Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>
Subject: Re: [ck] Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)

On 8/1/07, Ingo Molnar <mingo@...e.hu> wrote:
> > The only other thing of interest is that the -ck kernel had the WM
> > menus appear in about 3 seconds rather than 5-8 under the other two.
>
> under what load is that - 10 loops? There's no disk or network IO going
> on during a WM menu appearance, correct?

Incorrect.  This is before doing any tests whatsoever, just using the
menu to get to the launcher for nexuiz.  E-17 wants to load up pretty
little icons next to every menu item, and "games" is fourth down the
list of menus... the three above it contain practically everything
else installed on the system (since it includes Applications).
Thanks, debian menu! ;)

So obviously on first load these things aren't cached yet (in E's own
cache), so its madly searching the disk for pretty little icons.
After caching, the games menu pops up in 2 seconds.

For the newly-tested kernel (-ck+sched_yield_hack) it was 4-5 seconds
for initial load, same as CFS normally does for me.  I think the 8
second one was because I got in quick and the system was still running
some startup crap (so I blame disk i/o not the scheduler).  I'll keep
an eye on it just in case, but hardly consider it a regression at this
stage.

Thanks for the other experimentation hints, its always nice to have
that little extra bit of documentation!

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