[New: openFATE 308847] performance: improved scheduling
Feature added by: Michael Meeks (michael_meeks) Feature #308847, 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/308847
Feature changed by: Adrian Schröter (adrianSuSE) Feature #308847, revision 2 Title: performance: improved scheduling - Buildservice: New + Buildservice: Evaluation Priority Requester: Mandatory + Projectmanager: Neutral 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 :-) + Discussion: + #1: Adrian Schröter (adriansuse) (2010-01-21 11:50:44) + We slight different ideas, prefering the packages with source changes + and based on how often packages got downloaded. -- openSUSE Feature: https://features.opensuse.org/308847
Feature changed by: Michael Schröder (mlschroe) Feature #308847, revision 3 - Title: performance: improved scheduling + Title: performance: improved dispatcher - Buildservice: Evaluation + Buildservice: Duplicate of #308756 Priority Requester: Mandatory Projectmanager: Neutral 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: 308756 Discussion: #1: Adrian Schröter (adriansuse) (2010-01-21 11:50:44) We slight different ideas, prefering the packages with source changes and based on how often packages got downloaded. -- openSUSE Feature: https://features.opensuse.org/308847
participants (1)
-
fate_noreply@suse.de