Introduction:

Use case: 

As clusters get larger and workloads vary it is becoming critical that the jobs get evaluated in as short as time possible to ensure that the correct workload is being run. Using multiple schedulers to address this issue can allow for different scheduling policies and quicker turnaround time for large number of jobs or nodes.

Gist of design proposal::

PBS scheduler in it's current form can run easily run in multiple instances on the same machine. There are only two major problems that we have to deal with:


Design proposal mentioned below tends to address both these problem.

Forum discussion



Interface 2: Changes to PBS scheduler

Interface 3: Removed


Interface 4: Changes to PBS server.


Interface 5: Changes to PBS Nodes objects.


Interface 6: Changes to Queues.

Interface 7: How PBS server runs scheduler.


Interface 8: Changes to Reservations

Interface 9: Deleted

Interface 10: Fairshare


  1. What is not supported when multiple scheduler objects are present.

       2. Server's backfill_depth will be default value for all the schedulers in the complex.

            Ex: Default server's backfill_depth is 1 ,1 job per each scheduler will be backfilled 

                If server's backfill_depth is set to 5 , 5 jobs from each scheduler will get backfilled

3. The pbs_statsched() IFL will return the status of all PBS scheduler status. return type is pointer to list of batch_status structure (one for each scheduler)

4. PTL framework changes :

    Multiple scheduler information can be accessed by self.server.schedulers ,

    All scheduler functions can be called from a specific scheduler as self.server.schedulers['sched_name'].<method name>.

    There is a short hand created to server.schedulers as scheds, We can use this as self.scheds['sched_name'].<method name>.