linux-kernel - Re: CFS scheduler OLTP perforamnce

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 12 Dec 2008 14:38:20 +0100
From:	Peter Zijlstra <peterz@...radead.org>
To:	"Ma, Chinang" <chinang.ma@...el.com>
Cc:	Ingo Molnar <mingo@...e.hu>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"Wilcox, Matthew R" <matthew.r.wilcox@...el.com>,
	"Van De Ven, Arjan" <arjan.van.de.ven@...el.com>,
	"Styner, Douglas W" <douglas.w.styner@...el.com>,
	"Chilukuri, Harita" <harita.chilukuri@...el.com>,
	"Wang, Peter Xihong" <peter.xihong.wang@...el.com>,
	"Nueckel, Hubert" <hubert.nueckel@...el.com>
Subject: Re: CFS scheduler OLTP perforamnce

On Fri, 2008-12-12 at 13:12 +0100, Peter Zijlstra wrote:
> On Thu, 2008-12-11 at 16:25 -0700, Ma, Chinang wrote:
> > We are evaluating the CFS OLTP performance with 2.6.28-c7 kernel. In
> > this workload once a database foreground process commit a transaction
> > it will signal the log writer process to write to the log file.
> > Foreground processes will wait until log writer finish writing and
> > wake them up. With hundreds of foreground process running in the
> > system, it is important that the log writer get to run as soon as data
> > is available. 
> > 
> > Here are the experiments we have done with 2.6.28-rc7.
> > 1. Increase log writer priority "renice -20 <log writer pid>" while
> > keeping all other processes running in default CFS priority. We get a
> > baseline performance with log latency (scheduling + i/o) at 7 ms.
> 
> Is this better or the same than nice-0 ?
> 
> > 2. To reduce log latency, we set log writer to SCHED_RR with higher
> > priority. We tried "chrt -p 49  <log writer pid>" and got 0.7% boost
> > in performance with log latency reduced to 6.4 ms.

BTW, 6.4ms schedule latency sounds insanely long for a RR task, are you
running a PREEMPT=n kernel or something?

How would you characterize the log tasks behaviour?

 - does it run long/short (any quantization)
 - does it sleep long/short - how does it compare to its runtime?
 - does it wake others?
   - if so, always the one who woke it, or multiple others?


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