linux-kernel - Re: CFS review

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: <1185958161.6375.14.camel@Homer.simpson.net>
Date:	Wed, 01 Aug 2007 10:49:21 +0200
From:	Mike Galbraith <efault@....de>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Roman Zippel <zippel@...ux-m68k.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org
Subject: Re: CFS review

On Wed, 2007-08-01 at 09:36 +0200, Mike Galbraith wrote:
> On Wed, 2007-08-01 at 09:30 +0200, Ingo Molnar wrote:
>  
> > yeah, the posted numbers look most weird, but there's a complete lack of 
> > any identification of test environment - so we'll need some more word 
> > >from Roman. Perhaps this was run on some really old box that does not 
> > have a high-accuracy sched_clock()? The patch below should simulate that 
> > scenario on 32-bit x86.
> > 
> > 	Ingo
> > 
> > Index: linux/arch/i386/kernel/tsc.c
> > ===================================================================
> > --- linux.orig/arch/i386/kernel/tsc.c
> > +++ linux/arch/i386/kernel/tsc.c
> > @@ -110,7 +110,7 @@ unsigned long long native_sched_clock(vo
> >  	 *   very important for it to be as fast as the platform
> >  	 *   can achive it. )
> >  	 */
> > -	if (unlikely(!tsc_enabled && !tsc_unstable))
> > +//	if (unlikely(!tsc_enabled && !tsc_unstable))
> >  		/* No locking but a rare wrong value is not a big deal: */
> >  		return (jiffies_64 - INITIAL_JIFFIES) * (1000000000 / HZ);
> >  
> 
> Ah, thanks.  I noticed that clocksource= went away.  I'll test with
> stats, with and without jiffies resolution.

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  P COMMAND
6465 root      20   0  1432  356  296 R   30  0.0   1:02.55 1 chew
6462 root      20   0  1576  216  140 R   23  0.0   0:50.29 1 massive_intr_x
6463 root      20   0  1576  216  140 R   23  0.0   0:50.23 1 massive_intr_x
6464 root      20   0  1576  216  140 R   23  0.0   0:50.28 1 massive_intr_x

Well, jiffies resolution clock did upset fairness a bit with a right at
jiffies resolution burn time, but not nearly as bad as on Roman's box,
and not in favor of the sleepers.  With the longer burn time of stock
massive_intr.c (8ms burn, 1ms sleep), lower resolution clock didn't
upset it.

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  P COMMAND
6511 root      20   0  1572  220  140 R   25  0.0   1:00.11 1 massive_intr
6512 root      20   0  1572  220  140 R   25  0.0   1:00.14 1 massive_intr
6514 root      20   0  1432  356  296 R   25  0.0   1:00.31 1 chew
6513 root      20   0  1572  220  140 R   24  0.0   1:00.14 1 massive_intr

	-Mike

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