linux-kernel - Re: [git pull request] scheduler updates

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]

Date:	Fri, 24 Aug 2007 21:37:58 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [git pull request] scheduler updates

* Linus Torvalds <torvalds@...ux-foundation.org> wrote:

> On Fri, 24 Aug 2007, Ingo Molnar wrote:
> > 
> > Then there's also a change/tweak that increases the default 
> > granularity: it's still well below human perception so should not be 
> > noticeable, but servers win a bit from less preemption of CPU-bound 
> > tasks. (this is also the first step towards eliminating HZ from the 
> > granularity default calculation.)
> 
> Your explanation makes NO sense.
> 
> It doesn't eliminate HZ at all. It's still there, and it's still 
> totally bogus.

fair enough, and i fixed that.

( i called the previous patch the "first step" because i was too chicken
  to pick a single granularity default :-/ )

for the current queue i went for settings close to that of HZ=250 - 
that's the most common HZ variant that was tested previously. That means 
10 msec on a 1-way box, 20 msec on a 2-way box, 30 msec on a 4-way box, 
etc. (up to a 100 msecs ceiling.)

> Please just *remove* that thing. It has no possible value! You claim 
> that the preemption granularity is in "ns", and that it defaults to "3 
> msec", but it does no such thing at all, even with your patch. It 
> does:
> 
> 	unsigned int sysctl_sched_granularity __read_mostly = 3000000000ULL/HZ;
> 
> which is just total and utter CRAP!

ok, i've removed that and all the other HZ hacks too. I've uploaded a 
new queue with that fixed (and all other patches unchanged):

   git://git.kernel.org/pub/scm/linux/kernel/git/mingo/linux-2.6-sched.git

booted it on a number of boxes (32-bit and 64-bit). The question will be 
desktop behavior. I typically run my test-desktops with HZ=100 to make 
sure that desktop workloads are fine with large granularity values and 
coarse timers too, so i'm reasonably positive about this default.

We'll see - people can still readily tweak these values under 
CONFIG_SCHED_DEBUG=y and give us feedback, and if there's enough demand 
for very-finegrained scheduling (throughput be damned), we could 
introduce yet another config option or enable the runtime tunable 
unconditionally. (Or maybe the best option is Peter Zijlstra's adaptive 
granularity idea, that gives the best of both worlds.)

	Ingo

------------------>
Bruce Ashfield (1):
      sched: CONFIG_SCHED_GROUP_FAIR=y fixlet

Dmitry Adamushko (1):
      sched: optimize task_tick_rt() a bit

Ingo Molnar (3):
      sched: remove HZ dependency from the granularity default
      sched: tidy up and simplify the bonus balance
      sched: fix startup penalty calculation

Peter Zijlstra (2):
      sched: simplify bonus calculation #1
      sched: simplify bonus calculation #2

Sven-Thorsten Dietrich (1):
      sched: simplify can_migrate_task()

 sched.c      |    8 +-------
 sched_fair.c |   35 +++++++++++++++++++----------------
 sched_rt.c   |   11 ++++++++---
 3 files changed, 28 insertions(+), 26 deletions(-)
-
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/