Re: [ANNOUNCE][RFC] PlugSched-6.3.1 for 2.6.16-rc5

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Al Boldi wrote:
Peter Williams wrote:
Al Boldi wrote:
Peter Williams wrote:
Al Boldi wrote:
Control parameters for the scheduler can be read/set via files in:

/sys/cpusched/<scheduler>/
The default values for spa make it really easy to lock up the system.
Which one of the SPA schedulers and under what conditions?  I've been
mucking around with these and may have broken something.  If so I'd
like to fix it.
spa_no_frills, with a malloc-hog less than timeslice.  Setting
promotion_floor to max unlocks the console.
OK, you could also try increasing the promotion interval.

Seems that this will only delay the lock in spa_svr but not inhibit it.

OK. But turning the promotion mechanism off completely (which is what setting the floor to the maximum) runs the risk of a runaway high priority task locking the whole system up. IMHO the only SPA scheduler where it's safe for the promotion floor to be greater than MAX_RT_PRIO is spa_ebs. So a better solution is highly desirable.

I'd like to fix this problem but don't fully understand what it is. What do you mean by a malloc-hog? Would it possible for you to give me an example of how to reproduce the problem?


It should be noted that spa_no_frills isn't really expected to behave
very well as it's a pure round robin scheduler.

It's a bare bone scheduler that allows to prioritize procs to the admins desire, instead of leaving the priority management to the scheduler, which may be undesirable for some but not all.

OK. But it's important to realize that "nice" does not (in general) control the "amount of CPU" that tasks get with this scheduler. It merely controls the order in which runnable tasks run i.e. it's a "priority based" interpretation of "nice" not an "entitlement based" interpretation. The difference is important.

If you want a "bare bones" scheduler with an "entitlement based" interpretation of "nice" use spa_ebs with the maximum bonuses set to zero. In that state spa_ebs is safe for promotion to be completely disabled unless you also want to use cpu caps (in which case you'd need to set the floor to about 137 to make sure that capped tasks don't get completely starved).


It's intended purpose is as a basis for more sophisticated schedulers.

And that's why the same problem exists in the child scheds, i.e. spa_ws, spa_svr, zaphod, but not spa_ebs.

OK.


I've been thinking
about removing it as a bootable scheduler and only making its children
available but I find it useful to compare benchmark and other test
results from it with that from the other schedulers to get an idea of
the extra costs involved.

Thanks,
Peter
--
Peter Williams                                   [email protected]

"Learning, n. The kind of ignorance distinguishing the studious."
 -- Ambrose Bierce
-
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]
  Powered by Linux