linux-kernel - Re: Make yield_task

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]

Message-ID: <47BD3B56.3090404@linux.vnet.ibm.com>
Date:	Thu, 21 Feb 2008 14:20:30 +0530
From:	Balbir Singh <balbir@...ux.vnet.ibm.com>
To:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
CC:	Ingo Molnar <mingo@...e.hu>,
	Peter Zijlstra <peter@...gramming.kicks-ass.net>,
	Srivatsa Vaddagiri <vatsa@...ux.vnet.ibm.com>,
	Dhaval Giani <dhaval@...ux.vnet.ibm.com>,
	linux-kernel@...r.kernel.org,
	"Zhang, Yanmin" <yanmin_zhang@...ux.intel.com>
Subject: Re: Make yield_task_fair more efficient

Peter Zijlstra wrote:
> On Thu, 2008-02-21 at 13:09 +0530, Balbir Singh wrote:
> 
>> sched_yield() is supported API
> 
> For SCHED_FIFO/SCHED_RR.
> 
>>  and also look at http://lkml.org/lkml/2007/9/19/351.
> 
> Read on (http://lkml.org/lkml/2007/9/19/371) and find:
>         
>         The sched_yield() behaviour is actually very well-defined for RT
>         tasks (now, whether it's a good interface to use or not is still
>         open to debate, but at least it's a _defined_ interface ;), and
>         I think we should at least try to approximate that behaviour for
>         normal tasks, even if they aren't RT.
> 
> sched_yield() just isn't a very useful API except in RT and even there
> one can question it.
> 

But it's being used very heavily by existing applications. Can we break/penalize
them because we think it's not a good interface or a method to program?


>> I am trying to make sched_yield() efficient
>> when compat_sched_yield is turned on (which is most likely), since people will
>> want that behaviour (Hint, please read the man-page for sched_yield).
> 
> I did, so what? read the POSIX spec - its just plain undefined for
> SCHED_OTHER. We already do something 'sensible' for those few broken
> applications relying on unspecified behaviour.
> 
>> There are
>> already several applications using sched_yield(), so they all suffer.
> 
> Who is using it, where is their source so we can show its faster to not
> use it?
> 
> Really, hiding behind closed sores doesn't make it good.
> 
> 

I am not hiding behind closed source. Please refer to the regression reported by
Yanmin where he used compat_sched_yield=1 (see
http://lkml.org/lkml/2008/2/18/7). The regression might be due to other reasons,
but the point is that people are using compat_sched_yield=1

If you insist that sched_yield() is bad, I might agree, but how does my patch
make things worse. In my benchmarks, it has helped the sched_yield case, why is
that bad? As far as touching the hot-path is concerned, give me a benchmark that
I can run on my desktop, that will convince you that the overhead of the patch
is not all that high. If there is an overhead that is very visible, I'll stop
pushing the patch.

-- 
	Warm Regards,
	Balbir Singh
	Linux Technology Center
	IBM, ISTL
--
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/