Editing
CPU and 'vsched'
(section)
From Linix VServer
Jump to navigation
Jump to search
Warning:
You are not logged in. Your IP address will be publicly visible if you make any edits. If you
log in
or
create an account
, your edits will be attributed to your username, along with other benefits.
Anti-spam check. Do
not
fill this in!
==vscheduling an application inside a vserver== You can also use vsched to pace any cpu intensive command, e.g.: vcontext --create -- \ vsched --fill-rate 30 \ --interval 100 \ --tokens 100 \ --tokens_min 30 \ --tokens_max 200 \ --cpu_mask 0 -- /bin/my_cpu_hog however, this is dependent upon the hard scheduler actually being enabled. If either the minimum is not reached yet, or the context is paused (a special flag) then the process will enter the new 'H' (on hold) state which doesn't allow it to do anything until the minfill has been reached again ... While playing with this stuff I've run into situations where a context has no tokens left, at which point you cannot even kill the processes in it. Don't panic - you can always reenter the context and call vsched with new parameters. So the pacing example should really be: vcontext --create -- \ vsched --fill-rate 30 \ --interval 100 \ --tokens 100 \ --tokens_min 30 \ --tokens_max 200 \ --cpu_mask 0 -- \ vattribute --flag sched_hard -- /bin/my_cpu_hog A load of 30 is not a real problem (in terms of CPU, anyway), if those processes have such a low priority that everything else on the system is pretty much real time. What you are seeing is probably just due to the context not getting enough penalisation by the time the load hits 30, or some secondary effect like disk load or memory exhaustion. Try it with a smaller bucket size. When a context goes on hold with runnable processes, those processes might not contribute to the visible load factor, but they could be said to still be runnable. So all you're doing is hiding the problem and underutilising your CPUs. Having said that, because the cpu scheduler tries to avoid process starvation (where a process gets no CPU at all), then if a context has a *lot* of processes then it will `exploit' the anti-starvation code into getting more CPU than allocated, without hard scheduling. To give you an indication, this is around the number of minimum time slices (MIN_TIMESLICE, 5ms) than fit into the starvation limit (MAX_SLEEP_AVG, 2.5s) - ie, a per-second CPU load of 500. Turning on the hard scheduling means letting processes starve. If you're happy to let processes starve then you can make the scheduler perform better in other ways - that is a classic trade-off in CPU scheduling. ---- Heh. I don't know if this is current behaviour or not, but I think the signals should really queue and the context will close as soon as the processes wake up and receive enough cycles to process them and exit. Sending -KILL signals would clean it up pretty quickly (as soon as enough tokens are allocated for the processes to run), as chances are they won't consume any tokens to receive a KILL signal. Though, it would be nice if they didn't need tokens allocated to be stopped via KILL. ----
Summary:
Please note that all contributions to Linix VServer may be edited, altered, or removed by other contributors. If you do not want your writing to be edited mercilessly, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource (see
Linix VServer:Copyrights
for details).
Do not submit copyrighted work without permission!
Cancel
Editing help
(opens in new window)
Navigation menu
Page actions
Page
Discussion
Read
Edit
History
Page actions
Page
Discussion
More
Tools
Personal tools
Not logged in
Talk
Contributions
Create account
Log in
About
Overview
Paper
News
Developers
Donations
Search
Getting Started
Downloads
FAQs
Documentation
Support
Participate
How to participate
Report a Bug
Communicate
Teams/Projects
Hall of Fame
Resources
Archives
Recent Wiki Changes
Pastebin
Related Projects
VServer Hosting
Happy VServer Users
Tools
What links here
Related changes
Special pages
Page information