Future Extensions of GS

Empty Group Cleanup Flag

Hierarchies can now be created using group scheduling configuration files and the gschedctrl tool. However, after an application uses the hierarchy, empty groups are left behind in the hierarchy.

• A flag should be created that can be set on a group that indicates that the group should be destroyed when all of the members have left the group.

  • This flag will use a new group flags variable and a new ioctrl to manipulate the flags.

• The mechanism for removing the group when the last task exits still needs to be determined.

  • Removing the group

    • a call to gsched_remove_group

      • uninstalls the group from the top sequential group
      • uses the lock of the group being removed and the lock of the top sequential group

    • a call to gsched_destroy_group(actually, probably jsut similar code to part of this function)

      • uses gsched_lock and the lock of the group being destroyed

  • The obvious place to chedk if the group needs to be removed is in ‘gsched_task_exit’ which is called when a task exits.

    • It is unclear if the group can directly be removed/destroyed here.

      • The task_rq_lock and the task->gsched_lock are both held.

    • It seems safe to at least call gsched_remove_group.

      • group locking occurs inside of run queue and per task locking inside gsched_remove_task

    • The primariy issues is if it is safe to destroy the group

      • Specifically, is it safe to acquire the gsched_lock in this context?

• Alternate solution

  • group scheduling work qeuue

    • a new work queue could be created to do deferred processing for group scheduling

      • or the dski work queue could be renamed to be a general purpose kusp work queue

    • Instead of destroying the group directly from ‘gsched_task_exit’,

      an item cuould be placed on a work queue to destroy the group later on.

    • This would provide a better context.

• Additional comments have been added to kernel/gsched_core.c with the tag FIXME_TYRIAN.