Message-ID: <8cd998d50703101828l71fbec7bi9a819ad7b7fd9828@mail.gmail.com>
Date:	Sun, 11 Mar 2007 13:28:22 +1100
From:	"Con Kolivas" <kernel@...ivas.org>
To:	"Matt Mackall" <mpm@...enic.com>
Cc:	linux-kernel <linux-kernel@...r.kernel.org>,
	"Andrew Morton" <akpm@...ux-foundation.org>, ck@....kolivas.org
Subject: Re: RSDL-mm 0.28

On 11/03/07, Matt Mackall <mpm@...enic.com> wrote:
> I've tested -mm2 against -mm2+noyield and -mm2+rsdl+noyield. The
> noyield patch simply makes the sched_yield syscall return immediately.
> Xorg and all tests are run at nice 0.
>
> Loads:
>  memload: constant memcpy of 16MB buffer
>  execload: constant re-exec of a trivial shell script
>  forkload: constant fork and exit of a trivial shell script
>  make -j 5: hot-cache kernel build without ccache
>  make -j 5 ccache: hot-cache kernel build with ccache
>
> Tests:
>  beryl - 3D window manager, wiggle windows, spin desktop, etc.
>  galeon - web browser, rapidly scrolling long web pages by grabbing
>     the scroll bar
>  mp3 - XMMS on a FUSE sshfs over wireless (during all tests)
>  terminal - responsiveness of ssh and local terminal sessions
>  mouse - responsiveness of mouse pointer
>
> Results:
>  great = completely smooth
>  good = fully responsive
>  ok = visible latency
>  bad = becomes difficult to use (or mp3 skips)
>  awful = make it stop, please
>
>           -mm2        -mm2+noyield   rsdl+noyield
> no load
>  beryl    great       great          great
>  galeon   good        good           good
>  mp3      good        good           good
>  terminal good        good           good
>  mouse    good        good           good
> memload x10
>  beryl    awful/bad   great          good
>  galeon   good        good           ok/good
>  mp3      good        good           good
>  terminal good        good           good
>  mouse    good        good           good
> execload x10
>  beryl    awful/bad   bad/good       good
>  galeon   good        bad/good       ok/good
>  mp3      good        bad            good
>  terminal good        bad/good       good
>  mouse    good        bad/good       good
> forkload x10
>  beryl    good        good           great
>  galeon   good        good           ok/good
>  mp3      good        good           good
>  terminal good        good           ok/good
>  mouse    good        good           good
> make -j 5
>  beryl    ok          good           good/great
>  galeon   good        good           ok/good
>  mp3      good        good           good
>  terminal good        good           good
>  mouse    good        good           good
> make -j 5 ccache
>  beryl    ok          good           awful
>  galeon   good        good           bad
>  mp3      good        good           bad
>  terminal good        good           bad/ok
>  mouse    good        good           bad/ok
>
> make -j 5
> real      8m1.857s    8m50.659s      8m9.282s
> user      7m19.127s   8m3.494s       7m30.740s
> sys       0m30.910s   0m33.722s      0m29.542s
>
> make -j 5 ccache
> real      2m6.182s    2m19.032s      2m1.832s
> user      1m39.466s   1m48.787s      1m37.250s
> sys       0m19.741s   0m22.993s      0m20.109s

Thanks very much for that comprehensive summary and testing!

> There's a substantial performance hit for not yield, so we probably
> want to investigate alternate semantics for it. It seems reasonable
> for apps to say "let me not hog the CPU" without completely expiring
> them. Imagine you're in the front of the line (aka queue) and you
> spend a moment fumbling for your wallet. The polite thing to do is to
> let the next guy in front. But with the current sched_yield, you go
> all the way to the back of the line.

Well... are you advocating we change sched_yield semantics to a
gentler form? This is a cinch to implement but I know how Ingo feels
about this. It will only encourage more lax coding using sched_yield
instead of proper blocking (see huge arguments with the ldap people on
this one who insist it's impossible not to use yield).

> RSDL makes most of the noyield hit back in normal make and then some
> with ccache. Impressive. But ccache is still destroying interactivity
> somehow. The ccache effect is fairly visible even with non-parallel
> 'make'.

Ok I don't think there's any actual accounting problem here per se
(although I did just recently post a bugfix for rsdl however I think
that's unrelated). What I think is going on in the ccache testcase is
that all the work is being offloaded to kernel threads reading/writing
to/from the filesystem and the make is not getting any actual cpu
time. This is "worked around" in mainline thanks to the testing for
sleeping on uninterruptible sleep in the interactivity estimator. What
I suspect is happening is kernel threads that are running nice -5 are
doing all the work on make's behalf in the setting of ccache since it
is mostly i/o bound. The reason for -nice values on kernel threads is
questionable anyway. Can you try renicing your kernel threads all to
nice 0 and see what effect that has? Obviously this doesn't need a
recompile, but is simple enough to implement in kthread code as a new
default.

> Also note I could occassionally trigger nasty multi-second pauses with
> -mm2+noyield under exectest that didn't show up elsewhere. That's
> probably a bug in the mainline scheduler.

Ew. It's probably not a bug but a good example of some of the
starvation scenarios we're hitting on mainline (hence the need for a
rewrite ;))

Thanks!

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