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: <20070927133123.GA6901@elte.hu>
Date:	Thu, 27 Sep 2007 15:31:23 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Jarek Poplawski <jarkao2@...pl>
Cc:	David Schwartz <davids@...master.com>,
	"Linux-Kernel@...r. Kernel. Org" <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


* Jarek Poplawski <jarkao2@...pl> wrote:

> On Thu, Sep 27, 2007 at 11:46:03AM +0200, Ingo Molnar wrote:
[...]
> > What you missed is that there is no such thing as "predictable yield 
> > behavior" for anything but SCHED_FIFO/RR tasks (for which tasks CFS does 
> > keep the behavior). Please read this thread on lkml for a more detailed 
> > background:
> > 
> >    CFS: some bad numbers with Java/database threading [FIXED]
> > 
> >    http://lkml.org/lkml/2007/9/19/357
> >    http://lkml.org/lkml/2007/9/19/328
> > 
> > in short: the yield implementation was tied to the O(1) scheduler, so 
> > the only way to have the exact same behavior would be to have the exact 
> > same core scheduler again. If what you said was true we would not be 
> > able to change the scheduler, ever. For something as vaguely defined of 
> > an API as yield, there's just no way to have a different core scheduler 
> > and still behave the same way.
> > 
> > So _generally_ i'd agree with you that normally we want to be bug for 
> > bug compatible, but in this specific (iperf) case there's just no point 
> > in preserving behavior that papers over this _clearly_ broken user-space 
> > app/thread locking (for which now two fixes exist already, plus a third 
> > fix is the twiddling of that sysctl).
> > 
> 
> OK, but let's forget about fixing iperf. Probably I got this wrong, 
> but I've thought this "bad" iperf patch was tested on a few nixes and 
> linux was the most different one. The main point is: even if there is 
> no standard here, it should be a common interest to try to not differ 
> too much at least. So, it's not about exactness, but 50% (63 -> 95) 
> change in linux own 'definition' after upgrading seems to be a lot. 
> So, IMHO, maybe some 'compatibility' test could be prepared to compare 
> a few different ideas on this yield and some average value could be a 
> kind of at least linux' own standard, which should be emulated within 
> some limits by next kernels?

you repeat your point of "emulating yield", and i can only repeat my 
point that you should please read this:

    http://lkml.org/lkml/2007/9/19/357

because, once you read that, i think you'll agree with me that what you 
say is simply not possible in a sane way at this stage. We went through 
a number of yield implementations already and each will change behavior 
for _some_ category of apps. So right now we offer two implementations, 
and the default was chosen empirically to minimize the amount of 
complaints. (but it's not possible to eliminate them altogether, for the 
reasons outlined above - hence the switch.)

	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/