[New: openFATE 308849] performance: improved scheduling
Feature added by: Michael Meeks (michael_meeks) Feature #308849, revision 1 Title: performance: improved scheduling Buildservice: New Priority Requester: Mandatory Requested by: Michael Meeks (michael_meeks) Description: Currently, the global scheduling of packages appears rather crude. Some annoying things are - just looking at what is 'scheduled' in a single project (eg. Moblin) vs. 'building' - it would be nice to prioritise packages with a larger number of dependencies - at least within that Project. Then - the scheduler can more quickly, get a better overview of what is waiting to be built. Occassionally when we trigger a full re-build, we have bottlenecks that can be as thin as one or two packages; and it is sad to see them competing with some (immensely wide) openSUSE package-set: even though these key packages (which are competing against tens of other openSUSE pkgs), when built might enable ten others to build. Either way - first prioritising by project, to ensure an even balance of building, is perhaps easier than by dependency spread. Of course - perhaps what is there is 'fair' already, but it doesn't (somehow) seem that way; and it is unclear to me that the algorithms have been designed with the use-case of a vast re-build job running constantly in competition to any given task :-) -- openSUSE Feature: https://features.opensuse.org/308849
Feature changed by: Michael Meeks (michael_meeks) Feature #308849, revision 2 Title: performance: improved scheduling - Buildservice: New + Buildservice: Duplicate of #308847 Priority Requester: Mandatory Requested by: Michael Meeks (michael_meeks) Description: Currently, the global scheduling of packages appears rather crude. Some annoying things are - just looking at what is 'scheduled' in a single project (eg. Moblin) vs. 'building' - it would be nice to prioritise packages with a larger number of dependencies - at least within that Project. Then - the scheduler can more quickly, get a better overview of what is waiting to be built. Occassionally when we trigger a full re-build, we have bottlenecks that can be as thin as one or two packages; and it is sad to see them competing with some (immensely wide) openSUSE package-set: even though these key packages (which are competing against tens of other openSUSE pkgs), when built might enable ten others to build. Either way - first prioritising by project, to ensure an even balance of building, is perhaps easier than by dependency spread. Of course - perhaps what is there is 'fair' already, but it doesn't (somehow) seem that way; and it is unclear to me that the algorithms have been designed with the use-case of a vast re-build job running constantly in competition to any given task :-) + Relations: + - feature/duplicate: 308847 -- openSUSE Feature: https://features.opensuse.org/308849
participants (1)
-
fate_noreply@suse.de