linux-kernel - Re: [PATCH v3] sched/fair: Add advisory flag for borrowing a timeslice

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: <5474DAAF.2050300@oracle.com>
Date:	Tue, 25 Nov 2014 12:38:23 -0700
From:	Khalid Aziz <khalid.aziz@...cle.com>
To:	Mike Galbraith <umgwanakikbuti@...il.com>
CC:	Thomas Gleixner <tglx@...utronix.de>, corbet@....net,
	mingo@...hat.com, hpa@...or.com, peterz@...radead.org,
	riel@...hat.com, akpm@...ux-foundation.org, rientjes@...gle.com,
	ak@...ux.intel.com, mgorman@...e.de, liwanp@...ux.vnet.ibm.com,
	raistlin@...ux.it, kirill.shutemov@...ux.intel.com,
	atomlin@...hat.com, avagin@...nvz.org, gorcunov@...nvz.org,
	serge.hallyn@...onical.com, athorlton@....com, oleg@...hat.com,
	vdavydov@...allels.com, daeseok.youn@...il.com,
	keescook@...omium.org, yangds.fnst@...fujitsu.com,
	sbauer@....utah.edu, vishnu.ps@...sung.com, axboe@...com,
	paulmck@...ux.vnet.ibm.com, linux-kernel@...r.kernel.org,
	linux-doc@...r.kernel.org, linux-api@...r.kernel.org
Subject: Re: [PATCH v3] sched/fair: Add advisory flag for borrowing a timeslice

On 11/25/2014 10:46 AM, Mike Galbraith wrote:
> On Tue, 2014-11-25 at 07:50 -0700, Khalid Aziz wrote:
>
>> It is definitely not an attempt to solve any kind of RT problem.
>
> No no, I'm saying that giving certain tasks special dispensations
> effectively elevates them.  Temporarily or otherwise, they play by
> different rules, will block more deserving tasks, and it's not cut and
> dried that that blocking will not do more harm than good.
>
> Is it a clear win to make say some kworker or other global asset wait
> when it could have preempted and been gone in usecs?  Nope.

I understand. You are right, this allows some apps to gain special 
dispensation. On a general purpose system, I agree this can be 
problematic and it is important that it be easy to disable this. This is 
why I added sysctl tunable and made "disabled" the default state for 
this feature. Allowing temporary elevation of a task as part of the 
overall system design is ok when it is intentional and done after 
considering impact on other tasks running on the system. A large 
database server typically is not a general purpose server that runs any 
arbitrary tasks. These systems are tweaked in many ways to ensure 
optimal performance for database and not necessarily other apps. This 
patch gives admins one more knob to turn when maximizing performance. 
Any general purpose system that sees no use for this feature can leave 
this feature in its default state of disabled. I can see usefulness of 
this patch for other servers used in telecommunication infrastructure 
for instance, where the server is dedicated to specific task(s) and 
needs to update critical database with minimal contention, for example 
switch map on a telco switch controller or channel allocation map on a 
base station controller. I am sure people more familiar with other 
industries can see usefulness in other dedicated applications.

Thanks,
Khalid

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