* Linus Torvalds <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
