linux-kernel - Re: [ANNOUNCE][PATCH] Rotary Interactivity Favor Scheduler V2 Releaae

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:	Sat, 12 May 2012 12:15:05 +0800
From:	mou Chen <hi3766691@...il.com>
To:	linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...nel.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Juri Lelli <juri.lelli@...il.com>,
	Con Kolivas <kernel@...ivas.org>
Subject: Re: [ANNOUNCE][PATCH] Rotary Interactivity Favor Scheduler V2 Releaae

On Sat, May 12, 2012 at 1:06 AM, mou Chen <hi3766691@...il.com> wrote:
> Hmm. The new version is released.;-)
>
> The RIFS SCHEDULER is a scheduler for a low latency desktop. It is
> implemented base on the concept of simple.It lets the interactive task
> run first than the cpu bound task.
>
> First , RIFS is based on the multiple feedback queue algorithm. That
> means it will let the high priority process run first. After the task
> has run out of timeslice or it sleeps for waiting something RIFS will
> determine whether we should increase the prio or not.For.preemption we
> just need to compare the prio to determine whether it can preempt or
> not.
>
> If a task run out of time_sluce we.will.decrease it 's prio.
> If a task run half of the time_slice and sleep we will increase it's prio
> In the other case we will save the time_slice.
> If a task that has a higher prio than his static_prio run out of
> time_slice, we will drop it's priority to the static_prio.
> If a task run out of time_slice and it's prio has become 140 already,
> we will raise it's prio to static_prio.
>
>                             Chen
Actually the scheduler use these 5 method to prevent the happen of
starveness and enhance the interactivity and responsiveness. Making
the end user feeling smooth is the goal of RIFS.

This is the benchmark given by "latt":

Parameters: min_wait=100ms, max_wait=500ms, clients=1

-=-=-=-=-=-=-=-=-=-=-=-BFS-=-=-=-=-=-=-=-=-=-=-=-
Wakeup averages
-------------------------------------
	Max		      23 usec
	Avg		       8 usec
	Stdev		       3 usec
	Stdev mean	       0 usec

Work averages
-------------------------------------
	Max		   22469 usec
	Avg		   20069 usec
	Stdev		     286 usec
	Stdev mean	      28 usec


-=-=-=-=-=-=-=-=-=-=-=-RIFS-=-=-=-=-=-=-=-=-=-=-=-
Wakeup averages
-------------------------------------
	Max		      13 usec
	Avg		       4 usec
	Stdev		       1 usec
	Stdev mean	       0 usec

Work averages
-------------------------------------
	Max		   20086 usec
	Avg		   19706 usec
	Stdev		      82 usec
	Stdev mean	       8 usec


It seems that RIFS has a even lower scheduling latency on an full idle box.
Actually the difference between RIFS and BFS also CFS will become
significant under a heavy workload for example make -j256 or even make
-j512. Firefox is still smooth even make -j512 on a 3.3.x kernel with
RIFS.
--
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/