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.
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!
Why the hell can't you just make the code sane and do what the comment
*says* it does, and just admit that HZ has nothing what-so-ever to do with
that thing, and then you do
unsigned int sysctl_sched_granularity __read_mostly = 3000000ULL;
and be done with it. Instead of this *insane* expectation that HZ is
always 1000, and any other value means that you want bigger granularity,
which is not true and makes no sense.
So dammit, stop writing these totally bogus "explanations". If you have a
reason why the granularity needs to be HZ-dependent, *document* that
reason, and make the code actually match the comment, instead of
continually documenting things that SIMPLY ARE NOT TRUE.
Ingo, I'm not going to pull this kind of antics and crap.
Linus
-
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]
