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: <20070604195951.GJ11115@waste.org>
Date:	Mon, 4 Jun 2007 14:59:51 -0500
From:	Matt Mackall <mpm@...enic.com>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Rusty Russell <rusty@...tcorp.com.au>, akpm@...ux-foundation.org,
	Linux-kernel@...r.kernel.org
Subject: Re: Interesting interaction between lguest and CFS

On Mon, Jun 04, 2007 at 09:40:38PM +0200, Ingo Molnar wrote:
> 
> * Matt Mackall <mpm@...enic.com> wrote:
> 
> > > ah, so both the shell and the 'competing' CPU hog was running within 
> > > the same lguest instance?
> > 
> > No.
> > 
> > The CPU hog is running in the host. A single instance of lguest using 
> > busybox is started in another shell. When it reaches a shell prompt, 
> > -that- shell is occassionally unresponsive for long stretches.
> 
> so the shell within lguest is affected by the CPU hog outside? Could you 
> send me the sched-debug stats of the CPU hog and of the lguest host 
> process as well? (or were those amongst the ones you already sent?)

I sent you the stats for:

- both lguest processes
- the bash which started lguest (which I suspect you don't actually
  want)
- the gnome-terminal that lguest was running inside of
  (keystrokes to the shell in lguest go through that terminal)

The last is probably not very interesting either, as gnome-terminal is
a single process with multiple windows and none of the other windows
were affected.

So I sent you everything but the stats for the CPU hog.

I suggest you try this yourself - lguest is incredibly easy to get up
and running. It's also quite useful: I can test-boot kernels with it
in less than a second, or about 10x faster than basic qemu, and 100x
faster than a real boot. And as it uses a pty as console, you can do
things like pipe it through grep.

You'll need the following tab-damaged patch for rc3-mm1:

--- mm.orig/arch/i386/kernel/sched-clock.c      2007-06-04 12:15:51.000000000 -0500
+++ mm/arch/i386/kernel/sched-clock.c   2007-06-04 12:15:57.000000000
-0500
@@ -133,7 +133,7 @@ static void resync_freq(void *arg)
        struct sc_data *sc = &__get_cpu_var(sc_data);
 
        sc->sync_base = jiffies;
-       if (!cpu_has_tsc) {
+       if (!cpu_has_tsc || tsc_disable) {
                sc->unstable = 1;
                return;
        }

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