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: <20071002060607.GA18588@elte.hu>
Date:	Tue, 2 Oct 2007 08:06:07 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	David Schwartz <davids@...master.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: Network slowdown due to CFS

* David Schwartz <davids@...master.com> wrote:

> > These are generic statements, but i'm _really_ interested in the 
> > specifics. Real, specific code that i can look at. The typical Linux 
> > distro consists of in execess of 500 millions of lines of code, in 
> > tens of thousands of apps, so there really must be some good, valid 
> > and "right" use of sched_yield() somewhere in there, in some 
> > mainstream app, right? (because, as you might have guessed it, in 
> > the past decade of sched_yield() existence i _have_ seen my share of 
> > sched_yield() utilizing user-space code, and at the moment i'm not 
> > really impressed by those examples.)
> 
> Maybe, maybe not. Even if so, it would be very difficult to find. 
> [...]

google.com/codesearch is your friend. Really, 

> Note that I'm not saying this is a particularly big deal. And I'm not 
> calling CFS' behavior a regression, since it's not really better or 
> worse than the old behavior, simply different.

yes, and that's the core point.

> I'm not familiar enough with CFS' internals to help much on the 
> implementation, but there may be some simple compromise yield that 
> might work well enough. How about simply acting as if the task used up 
> its timeslice and scheduling the next one? (Possibly with a slight 
> reduction in penalty or reward for not really using all the time, if 
> possible?)

firstly, there's no notion of "timeslices" in CFS. (in CFS tasks "earn" 
a right to the CPU, and that "right" is not sliced in the traditional 
sense) But we tried a conceptually similar thing: to schedule not to the 
end of the tree but into the next position. That too was bad for _some_ 
apps. CFS literally cycled through 5-6 different yield implementations 
in its 22 versions so far. The current flag solution was achieved in 
such an iterative fashion and gives an acceptable solution to all app 
categories that came up so far. [ and this is driven by compatibility 
goals - regardless of how broken we consider yield use. The ideal 
solution is of course to almost never use yield. Fortunately 99%+ of 
Linux apps follow that ideal solution ;-) ]

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