[RFC] Static/Runtime CPU/IO bound scheduling polices based on CPU(s) to support complete spectrum of tasks

[RFC] Static/Runtime CPU/IO bound scheduling polices based on CPU(s) to support complete spectrum of tasks

[Jaswinder Singh Rajput]

I am planning to prepare the followings:

1. This will be also eligible for UP but more useful for SMPs having
multiple CPUs.

2. Here we can support static/runtime scheduling polices for each CPU
core.

3. Static scheduling polices can be allocated by using command
parameter.

4. In runtime scheduling polices where scheduling polices can be changed
at runtime.

5. Runtime scheduling will be further divided into User defined, Smart
scheduling (automatically by system) and Hybrid scheduling.

6. These scheduling policies can be CPU bound and/or IO bound or others.

7. These scheduling policies can be task based or can be group based say
firefox tasks or multimedia group.

8. By this way we can support complete spectrum of tasks say Non
real-time (NRT), Soft real-time(SRT) and Hard real-time (HRT) tasks.
Like NRT: CPU0, CPU1 and SRT: CPU2 and HRT: CPU3

9. Users can further divide the tasks as NRT, SRT and HRT and can also
change the priorities of each task or group of tasks if they want.

10. In User defined scheduling polices, user can set scheduling polices
for each CPU core at runtime and check what is the performance
(efficiency) of the system.

11. Users can also allocate the scheduling polices per CPU core based on
their requirement and can change it any time.

12. Users can specify which CPUs will work as NRT, SRT and HRT.

13. Users can specify scheduling policies for NRT, SRT and HRT.

14. User will check the performance (efficiency) of the system and also
take suggestion from system that which policy will be better for them.

15. In Smart scheduling policies, system will change the scheduling
polices based on performance (efficiency) of the system to get the
maximum efficiency.

16. Smart scheduling will decide which CPU will work as NRT, SRT and
HRT.

17. Smart scheduling will decide scheduling policies for NRT, SRT and
HRT.

18. In hybrid scheduling where both User defined and Smart scheduling
will work together.

19. In hybrid scheduling, user will define which CPUs will work as User
defined and which CPU will work as Smart scheduling.

20. We can also see the status of the overall system performance and
also based on HRT, SRT and NRT.

Thanks,
--
JSR

Re: [RFC] Static/Runtime CPU/IO bound scheduling polices based on CPU(s) to support complete spectrum of tasks

[Andi Kleen]

On Tue, Apr 07, 2009 at 03:55:31PM +0530, Jaswinder Singh Rajput wrote:
> I am planning to prepare the followings:

This seems all quite vague. Perhaps it would be good if you started
with a clear definition what problem you're trying to solve.

-Andi

-- 
ak@linux.intel.com -- Speaking for myself only.

Re: [RFC] Static/Runtime CPU/IO bound scheduling polices based on CPU(s) to support complete spectrum of tasks

[Jaswinder Singh Rajput]

On Tue, 2009-04-07 at 12:58 +0200, Andi Kleen wrote:
> On Tue, Apr 07, 2009 at 03:55:31PM +0530, Jaswinder Singh Rajput wrote:
> > I am planning to prepare the followings:
> 
> This seems all quite vague. Perhaps it would be good if you started
> with a clear definition what problem you're trying to solve.
> 

This will solves 2 major problems:

1. Support complete task spectrum (Hard/soft/non Realtime) on one
system.

2. Take Maximum advantage of the each CPU core and treat each CPU core
as a System. So we can take maximum utilization of the Hardware.

--
JSR

Re: [RFC] Static/Runtime CPU/IO bound scheduling polices based on CPU(s) to support complete spectrum of tasks

[Jaswinder Singh Rajput]

On Tue, 2009-04-07 at 17:02 +0530, Jaswinder Singh Rajput wrote:
> On Tue, 2009-04-07 at 12:58 +0200, Andi Kleen wrote:
> > On Tue, Apr 07, 2009 at 03:55:31PM +0530, Jaswinder Singh Rajput wrote:
> > > I am planning to prepare the followings:
> > 
> > This seems all quite vague. Perhaps it would be good if you started
> > with a clear definition what problem you're trying to solve.
> > 
> 

I do not surprise, if this approach seems vague to many developers
because this is many years ahead of time.

If you can see the future, then you can see in next few years we will
get single processor with hundreds of symmetrical and asymmetrical cores
then we need to treat each core as a different system and each core will
be dedicated for specific use and task and we need different scheduling
polices for each core.

Even in embedded space, hundreds of small asymmetrical processors will
be compact into a single die to save power, space, communication and so
on.

> This will solves 2 major problems:
> 
> 1. Support complete task spectrum (Hard/soft/non Realtime) on one
> system.
> 
> 2. Take Maximum advantage of the each CPU core and treat each CPU core
> as a System. So we can take maximum utilization of the Hardware.

Further more this will create healthy competition in different
schedulers. And then we can see which scheduler is best for which case.

--
JSR

Re: [RFC] Static/Runtime CPU/IO bound scheduling polices based on CPU(s) to support complete spectrum of tasks

[Peter Zijlstra]

On Thu, 2009-04-09 at 15:56 +0530, Jaswinder Singh Rajput wrote:
> On Tue, 2009-04-07 at 17:02 +0530, Jaswinder Singh Rajput wrote:
> > On Tue, 2009-04-07 at 12:58 +0200, Andi Kleen wrote:
> > > On Tue, Apr 07, 2009 at 03:55:31PM +0530, Jaswinder Singh Rajput wrote:
> > > > I am planning to prepare the followings:
> > > 
> > > This seems all quite vague. Perhaps it would be good if you started
> > > with a clear definition what problem you're trying to solve.
> > > 
> > 
> 
> I do not surprise, if this approach seems vague to many developers
> because this is many years ahead of time.

Yes, or not.

For partitioning we have cpusets, for scheduler policies we have
sched_setscheduler().

The only thing we do not have are deadline schedulers, but people are
working on that -- its a rather complex piece of work.

The rest of you babbling is hand-waving about heuristics.

Re: [RFC] Static/Runtime CPU/IO bound scheduling polices based on CPU(s) to support complete spectrum of tasks

[Jaswinder Singh Rajput]

On Thu, 2009-04-09 at 13:38 +0200, Peter Zijlstra wrote:
> On Thu, 2009-04-09 at 15:56 +0530, Jaswinder Singh Rajput wrote:
> > On Tue, 2009-04-07 at 17:02 +0530, Jaswinder Singh Rajput wrote:
> > > On Tue, 2009-04-07 at 12:58 +0200, Andi Kleen wrote:
> > > > On Tue, Apr 07, 2009 at 03:55:31PM +0530, Jaswinder Singh Rajput wrote:
> > > > > I am planning to prepare the followings:
> > > > 
> > > > This seems all quite vague. Perhaps it would be good if you started
> > > > with a clear definition what problem you're trying to solve.
> > > > 
> > > 
> > 
> > I do not surprise, if this approach seems vague to many developers
> > because this is many years ahead of time.
> 
> Yes, or not.
> 
> For partitioning we have cpusets, for scheduler policies we have
> sched_setscheduler().
> 
> The only thing we do not have are deadline schedulers, but people are
> working on that -- its a rather complex piece of work.
> 
> The rest of you babbling is hand-waving about heuristics.

I do not know what you read and what you understand.

Can we change the schedulers at runtime ?

Can we specify:
 Task 1-100: Scheduler1
 Task 101-200: Scheduler2

--
JSR