* Nick Piggin <[email protected]> wrote:
> > yeah - but they'll all be quad core, so the SMP timeslice
> > multiplicator should do the trick. Most of the CFS testers use
> > single-CPU systems.
>
> But desktop users could have have quad thread and even 8 thread CPUs
> soon, so if the number doesn't work for both then you're in trouble.
> It just smells like a hack to scale with CPU numbers.
hm, i still like Con's approach in this case because it makes
independent sense: in essence we calculate the "human visible" effective
latency of a physical resource: more CPUs/threads means more parallelism
and less visible choppiness of whatever basic chunking of workloads
there might be, hence larger size chunking can be done.
> > it doesnt in any test i do, but again, i'm erring on the side of it
> > being more interactive.
>
> I'd start by erring on the side of trying to ensure no obvious
> performance regressions like this because that's the easy part.
> Suppose everybody finds your scheduler wonderfully interactive, but
> you can't make it so with a larger timeslice?
look at CFS's design and you'll see that it can easily take larger
timeslices :) I really dont need any reinforcement on that part. But i
do need reinforcement and test results on the basic part: _can_ this
design be interactive enough on the desktop? So far the feedback has
been affirmative, but more testing is needed.
server scheduling, while obviously of prime importance to us, is really
'easy' in comparison technically, because it has alot less human factors
and is thus a much more deterministic task.
> For _real_ desktop systems, sure, erring on the side of being more
> interactive is fine. For RFC patches for testing, I really think you
> could be taking advantage of the fact that people will give you
> feedback on the issue.
90% of the testers are using CFS on desktops. 80% of the scheduler
complaints come regarding the human (latency/behavior/consistency)
aspect of the upstream scheduler. (Sure, we dont want to turn that
around into '80% of the complaints come due to performance' - so i
increased the granularity based on your kbuild feedback to that near of
SD's, to show that mini-timeslices are not a necessity in CFS, but i
really think that server scheduling is the easier part.)
Ingo
-
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]
