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]
Date:	Fri, 9 Mar 2007 14:46:24 -0600
From:	Matt Mackall <mpm@...enic.com>
To:	Con Kolivas <kernel@...ivas.org>
Cc:	linux-kernel <linux-kernel@...r.kernel.org>,
	akpm@...ux-foundation.org
Subject: Re: 2.6.21-rc3-mm1 RSDL results

On Fri, Mar 09, 2007 at 07:39:05PM +1100, Con Kolivas wrote:
> On Friday 09 March 2007 19:20, Matt Mackall wrote:
> > And I've just rebooted with NO_HZ and things are greatly improved. At
> > idle, Beryl effects are silky smooth (possibly better than stock) and
> > shows less load. Under 'make', Beryl is still responsive as is Galeon.
> > No sign of lagging mouse or typing.
> >
> > Under make -j 5, things are intermittent. Galeon scrolling is
> > sometimes still responsive, but Beryl, terminals and mouse still drag
> > quite a bit.
> 
> I just replied before you sent this one out I think our messages passed each 
> other across the ocean somewhere. I don't quite get what combination of 
> factors you're saying here caused great improvement. Was it enabling NO_HZ on 
> mainline cpu scheduler or disabling NO_HZ or on RSDL?

Ok, I've now disabled sched_yield (I'm using xorg radeon drivers).

So far:

          rc2-mm2   RSDL  RSDL+NO_HZ  RSDL+NO_HZ+no_yield  estimated CPU
no load
 beryl    good      good  great       great                ~30% at 600MHz
 galeon   good      good  good        good                 100% at 600MHz
 mp3      good      good  good        good                 < 5% at 600MHz
 terminal good      good  good        good                 ~0
 mouse    good      good  good        good                 ~0
make
 beryl              awful ok          good
 galeon             bad   ok          good
 mp3                good  good        good
 terminal           bad   good        good
 mouse              bad   good        good
make -j2
 beryl              awful             bad/ok
 metacity                             bad/ok  <- it's not beryl-specifc
 galeon             bad               bad/ok
 mp3                good              good
 terminal           bad               bad/ok
 mouse              bad               bad/ok
make -j5
 beryl    ok        awful awful       awful/bad
 galeon   ok        bad   bad         bad
 mp3      good      good  good        a couple skips
 terminal ok        bad   bad         bad
 mouse    good      bad   bad         bad
memload x5
 beryl                                ok/good
 galeon                               ok/good
 mp3                                  good
 terminal                             ok/good
 mouse                                ok/good 


good = no problems
ok = noticeable latency
bad = hard to use
awful = completely unusable

By the way, make -j5 is my usual kernel compile because it gives me
the best wall time on this box. 

A priori, this load should be manageable by RSDL as the interactive
loads are all pretty small. So I wrote a little Python script that
basically continuously memcpys some 16MB chunks of memory:

#!/usr/bin/python
a = "a" * 16 * 1024 * 1024
while 1:
    b = a[1:] + "b"
    a = b[1:] + "c"

I've got 1.5G of RAM, so I can run quite a few of these without
killing my pagecache. This should test whether a) Beryl's actually
running up against memory bandwidth issues and b) whether "simple"
static loads work. As you can see, running 5 instances of this script
leaves me in good shape still. 10 is still in "ok" territory, with top
showing each getting 9.7-10% of the CPU. 15 starts to feel sluggish.
20 the mouse jumps a bit and I got an MP3 skip. 30 is getting pretty
bad, but still not as bad as the make -j 5 load.

My suspicion is the problem lies in giving too much quanta to
newly-started processes.

-- 
Mathematics is the supreme nostalgia of our time.
-
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