From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on sa.local.altlinux.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,RP_MATCHES_RCVD,SUBJ_ALL_CAPS autolearn=ham autolearn_force=no version=3.4.1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=imath.kiev.ua; s=hydra; t=1519654959; bh=X0AvL7p5sG4TtmYeuWkEIvv26yKaIiAgZgTlXcI44io=; h=Date:From:To:Subject; b=H6mA6zqeA70u8pmKOa2O3McfXDxmN3tqg8deT4s1Xvi+L7+g5aj5pJeh0UFFo1vtZ xZ12+/4+kOH4gUGnH/vV1MWuzC1jQluTjnWwvQn+oWgmVG0lGQnT76t192OD1+n41K PinwPkPf46FuM29pk3StjMXdTUPMJKQ4TaUm4lTQ= Date: Mon, 26 Feb 2018 16:22:38 +0200 From: Igor Vlasenko To: devel@lists.altlinux.org Message-ID: <20180226142238.GA27109@dad.imath.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.9.1 (2017-09-22) Subject: [devel] =?utf-8?b?0KHQsdC+0YDQvtGH0L3QuNGG0LAgVi4g0J/Qu9Cw0L0=?= =?utf-8?b?0LjRgNC+0LLRidC40Lo=?= X-BeenThere: devel@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ALT Linux Team development discussions List-Id: ALT Linux Team development discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Feb 2018 14:22:42 -0000 Archived-At: List-Archive: List-Post: Уважаемые господа! Продолжаю цикл писем, посвященный предложениям по улучшению нашей сборочницы. V. Планировщик [процесс, запускающий task'и на сборку]. Я уже писал, что для повышения производительности планировщик и мержер транзакций надо разнести в полностью отдельные параллельно выполняемые независимые процессы. Пусть общаются только через смену статуса task'ов. Однако кроме этого в текущем планировщике есть и другие недостатки. Что мне больше всего не нравится в текущем планировщике, это как реализована для пользователя его эмуляция последовательной сборочницы. С одной стороны, она не полная, т.е. если пользователь залил таски T1 T2 T3, то нет гарантии, что они соберутся именно в последователоьности T1 T2 T3. Могут и в T2 T3 T1. С другой стороны, блокировку последовательной сборочницы планировщик честно эмулирует: если T1 собирается, то T2 и T3 никогда не будут отправлены на сборку, При этом, если T1 --- тяжелая транзакция, как существенное обновление python или texlive, то такая транзакция будет обрабатываться нашей сборочницей неделями, а то и месяцами. Планировщик, эмулируя блокировку последовательной сборочницы, по сути, банит пользователя на эту неделю, а то и месяц. IMHO, так не правильно. Если есть свободные вычислитльные ноды и AVAITING task'и, планировщик просто обязан помочь найти им друг друга. Ведь сборочница не должна простаивать? А проблема балансировки нагрузки решается, например, приоритетами. Чем больше у пользователя запущенных task'ов, тем ниже его приоритет у планировщика при запуске нового task'а. Далее, раз эмуляция последовательной сборочницы востребована, я предлагаю сделать для нее улучшения в интерфейсе пользователя (syntax sugar). К примеру, сейчас работа с task deps достаточно громоздка. Облегчить работу могла бы опция --after. Опция --after ",,...," в ssh girar build/run позволит быстро выставить task deps. Для тех, кому task deps слишком сложны в обслуживании, можно реализовать полноценную эмуляцию последовательной сборочницы. добавить в ssh girar build/run опцию --seq[uential]. Эта опция внутри будет выставлять task'у опцию sequential, а планировщик будет запускать task с опцией sequential только тогда, когда все таски с меньшими номерами либо DONE, либо FAILED. --- очень легко в реализации, и гораздо лучше, чем сейчас. -- I V