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:	Thu, 19 Mar 2015 03:38:14 +0100
From:	Mike Galbraith <umgwanakikbuti@...il.com>
To:	Mitchell Erblich <erblichs@...thlink.net>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: Linux Kernel Scheduling Addition Notification : Hybrid Sleepers
 and Unfair scheduling

On Wed, 2015-03-18 at 16:25 -0700, Mitchell Erblich wrote:

> 
> SCHED_IA
> 	Over 10 years ago, System V Release 4 was enhanced with additional
> features by Sun Microsystems. One of the more minor extensions dealt
> with the subdivision of process’s scheduling characteristics and was
> known as he INTERACTIVE /IA scheduling class. This scheduling class
> was targeted to frequent sleepers, with the mouse icon being one the
> first processes/tasks..
> 
> 	Linux has no explicit SCHED_IA scheduling policy, but does alter
> scheduling characteristics based on some sleep behavior (example:
> GENTLE_FAIR_SLEEPERS) within the fair share scheduling configuration
> option.

That's about fairness, it levels the playing field sleepers vs hogs.

>  Processes / tasks that are CPU bound that fit into a SLEEPER behavior
> can have a hybrid behavior over time where during any one scheduling
> period, it may consume its variable length allocated time. This can
> alter its expected short latency to be current / ONPROC. To simplify
> the implementation, it is suggested that SCHED_IA be a sub scheduling
> policy of SCHED_NORMAL. Shouldn’t an administrator be able to classify
> that the NORMAL long term behavior of a task, be one as a FIXED
> sleeper?

Nope, we definitely don't want a SCHED_IA class.

Your box can't tell if you're interacting or not even if you explicitly
define something as 'interactive'.  If I stare in fascination at an
eye-candy screen-saver, it becomes 'interactive'.  If I'm twiddling my
thumbs waiting for a kbuild whatever other CPU intensive job to finish,
that job becomes the 'interactive' thing of import.  The last thing I
want is to have to squabble with every crack-head programmer on the
planet who thinks his/her cool app should get special treatment.

You can't get there from here.
> 
> 	Thus, the first Proposal is to explicitly support the SCHED_IA
> scheduling policy within the Linux kernel. After kernel support, any
> application that has the same functionality as priocntl(1) then needs
> to be altered to support this new scheduling policy.
> 
> 
> Note: Administrator in this context should be a task with a UID, EUID,
> GID, EGID, etc, that has the proper CAPABILITY to alter scheduling
> behavior.

> 
> SCHED_UNFAIR

Snip.. we already have truckloads of bandwidth control.

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

Powered by blists - more mailing lists