Are groups in any sort of relation to each other? A heirarchy, for example?
Or is each group completely independent of the rest?
Can a process/thread change task-groups on the fly? If you were using it for
resources other than CPU.
> A task may call sys_set_tgroup_scheduler (int sched_id) to set its
Make sched_id a string. That way we can have dynamically loadable schedulers
without having to set up an int->name mapping.
> The current (toy) global scheduler just does round-robin
> scheduling of each thread group, allowing each one 1 jiffie of CPU
> time before allocating the CPU to another group. This is known to
> be simplistic, and is simply a demonstration. Obviously, in the
> default case, the init_tgroup, which contains all tasks, gets 100%
> of the CPU.
Have you looked at VSTa's scheduler? While it doesn't have a special notion of
a thread group, it has heirarchical dissemination of CPU time. A particular
thread gets some CPU time. If it doesn't use the whole slice, the remainder of
the time is given to its children. This is typically applied to multi-threaded
processes so that the whole process competes equally with other processes,
regardless of how many threads they each have.
Are you working on the assumption that all thread groups get the same share of
CPU, or do the groups themselves have shares/priorities?
> Another nice example would be a task group scheduler that exported a
> page of write-only memory to user-space, and allowed a user level
> thread system to scribble there to provide hints on the user level
> state of things. We end up with the best of scheduler activations
> (i.e. threads without the problems of either kernel threads or user
> threads) but with extremely low overhead.
How about mapping a datastructure into user-space to allow high-level
("strategic") scheduling decisions to be done in user mode? I don't know if
its actually possible, but I think its sufficiently interesting to look at.
J
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/