linux-kernel - Re: Network slowdown due to CFS

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: <20071002090346.GA1738@ff.dom.local>
Date:	Tue, 2 Oct 2007 11:03:46 +0200
From:	Jarek Poplawski <jarkao2@...pl>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Nick Piggin <nickpiggin@...oo.com.au>,
	David Schwartz <davids@...master.com>,
	linux-kernel@...r.kernel.org, Mike Galbraith <efault@....de>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Martin Michlmayr <tbm@...ius.com>,
	Srivatsa Vaddagiri <vatsa@...ux.vnet.ibm.com>,
	Stephen Hemminger <shemminger@...ux-foundation.org>
Subject: Re: Network slowdown due to CFS

On Mon, Oct 01, 2007 at 06:25:07PM +0200, Ingo Molnar wrote:
> 
> * Jarek Poplawski <jarkao2@...pl> wrote:
> 
> > BTW, it looks like risky to criticise sched_yield too much: some 
> > people can misinterpret such discussions and stop using this at all, 
> > even where it's right.
> 
> Really, i have never seen a _single_ mainstream app where the use of 
> sched_yield() was the right choice.
> 
> Fortunately, the sched_yield() API is already one of the most rarely 
> used scheduler functionalities, so it does not really matter. [ In my 
> experience a Linux scheduler is stabilizing pretty well when the 
> discussion shifts to yield behavior, because that shows that everything 
> else is pretty much fine ;-) ]
> 
> But, because you assert it that it's risky to "criticise sched_yield() 
> too much", you sure must know at least one real example where it's right 
> to use it (and cite the line and code where it's used, with 
> specificity)?

Very clever move! And I see some people have catched this...

Since sched_yeld() is a very general purpose tool, it can be easily
replaced by others, of course, just like probably half of all
system calls. And such things are done often in a code during
optimization. But, IMHO, the main value of sched_yield() is it's
easy to use and very readable way to mark some place. Sometimes
even test if such idea is reasonable at all... Otherwise, many such
possibilities could easily stay forgotten forever.

But you are right, the value of this call shouldn't be exaggerated,
and my proposal was an overkill. Anyway, it seems, there could be
imagined something better than current ways of doing this. They look
like two extremes and something in between and not too complicated
should suffice. Currently, I wonder if simply charging (with a key
recalculated) such a task for all the time it could've used isn't one
of such methods. It seems, it's functionally analogous with going to
the end of que of tasks with the same priority according to the old
sched.

Regards,
Jarek P.
-
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/