Scheduler and process/threads control API
Submitted by cy6erGn0m on Fri, 08/22/2008 - 14:49.
Here _early draft_ of doc, that should helps write PRD (product requirments document) for JNode scheduler and design of API to control processes.
But i need comments and help of community to take a right design decitions and choose best way before try to do something in kernel.
see document in attachment.
Of course i'll work on this document and write more details for every point of it.
| Attachment | Size |
|---|---|
| Nu scheduler.odt | 20.37 KB |
- Login to post comments
What's the status of this?
What's the status of this?
UPD
doc update. some additional details.
It's a very ineresting
It's a very ineresting document. Thanks for posting it!
As a first step towards creating new schedulers we need to make the scheduler configurable so that we can safely change one scheduler for an other. After this a new scheduler could be implemented besides the current one which could be gradually improved too.
JNode has no real support for processes yet. The plan is that the isolate will be the process but the current isolate implementation is focused on static data isolation while thread control, realible termination and many other aspects of isolates are still to be done.
Multiprocessor support is not reliable yet and it might be broken to to the point of preventing JNode to boot.
We should decide if we create separate schedulers for uniprocessor systems and multiprocessor systems. For instance quite a few points of your document make only sense in a multiprocessor system and they add significant complexity to the scheduler. The reason for this separartion is that JNode aims to be very flexible, targetting a wide range of processors and devices. Hence for small systems a special uniprocessor scheduler would be best both for space and performance reasons. Such scheduler could be aware of the presence of multiple procressors or cores in the system but it would deliberatly constrain itself to one processor or core and leave the others unused. Therefor it could be used also as a safe mode scheduler for minimal operational modes of the system.
Considering these things it might make sense to group the points of the document according to the order in which they could be implemented.
The first thing is to have configurable shceduler support so that we can relibale work on the new scheduler while the old is still in use and still avoid if possibel the creation of a new branch for this.
If we assume that our initial goal is to have a good scheduler for single processor systems then the following points could come next as they could be incremental improvements to the current scheduler:
- 5. performance counters
- 3. O(1) scheduler
- 8. fast tick implementation
The next level could be support for isolates which hopefully will make good progress while the points above are implemented:
- 9. Threads/processes control API and threading model
There are several points which make only sense in multiprocessor systems:
- 1. Processor affinity
- 2. Lightweight cores
- 7. Load balancing
Finally we can consider the creation of specialized shcedulers for various usecases of JNode like: interactive, server, realtime
- 6. dynamic priorities
- 4. Realtime vs classic scheduler
What do you think?
Yes, i think at first i'll
Yes, i think at first i'll try to implement (3) and ( 8 ). ( 8 ) partialy done (irq dispatchment is moved to separate daemon-thread and rewriten from unsafeSuspend/unsafeResume to wait/notify. Point ( 3 ) O(1) in progress.
Duaring it i investigate some points and try to develop good design and make a list of features that actually may be useful.
About many schedulers, of course it will be way to configure it. As minimum, i'll see to Solaris, when users also can switch schedulers on the fly and realtime scheduler can work with classic at ONE CPU. Currently i do not know how to do that, but i think now it's not a problem...
About performance counters.. it's not so easy as looks. Performance counters should be very fast and should not produce system degradation. But kernel profiler is a userful thing and it should be implemented and, like dtrace, it should be way dynamically turn on and off it on the fly.
Also, needs lightweight scheduler for embedded systems, but it is not a main priority of JNode, imho, JNode required too much memory to run it on many embedded systems. For example, my Linux-based cellular phone has just 8M ram and it works fast, JNode requires at least 192M with minimal shell (With 128M it crashes).