Лінус Торвальдс абверг праблемы з планавальнікам задач, якія ўсплылі ў тэсце прадукцыйнасці

Распрацоўшчык гульняў Malte Skarupke апублікаваў параўнанне прадукцыйнасці блакіровак на аснове Mutex и Спіналак пры выкарыстанні розных планавальнікаў задач. Тэсты паказалі анамальна вялікія затрымкі пры выкарыстанні Spinlock з па змаўчанні выкарыстоўваным у Linux планавальнікам задач. Аўтар тэстаў зрабіў выснову, што планавальнік задач Linux мае праблемы, якія негатыўна адбіваюцца на працы гульняў, якiя ствараюцца для сэрвісу Google Stadia, у якім гульні выконваюцца на GPU у хмарным асяроддзі, а кліенту ў струменевым рэжыме толькі транслюецца змесціва экрана з частатой да 60 кадраў у секунду. Пры падобных умовах неабходна забяспечыць своечасовую выснову кадраў на экран і затрымкі, якія перавышаюць мілісекунду, становяцца прыкметныя.

Да абмеркавання тэстаў падключыўся Лінус Торвальдс, які назваў іх смеццем (“pure garbage”) і прыкладам таго, як можна, цалкам не разабраўшыся ў тэме, атрымаць паказчыкі, якія не адлюстроўваюць рэальную рэчаіснасць. Spinlock з'яўляецца нізкаўзроўневым прымітывам, які ў прасторы карыстача трэба выкарыстоўваць з вялікай асцярожнасцю і цалкам разбіраючыся ў дэталях, інакш можна атрымаць тое, што было прадэманстравана аўтарам цеста. Распрацоўнікам гульняў Лінус параіў не прымяняць spinlock і не спрабаваць гарадзіць уласныя сістэмы блакіроўкі на яго аснове, а выкарыстоўваць існуючыя правераныя механізмы, якія інфармуюць сістэму аб чаканні вызвалення блакіроўкі для выключэння ўплыву планавальніка.

Надбудовы на базе Spinlock жа можна выкарыстоўваць толькі пры поўнай упэўненасці, што планавальнік не перапыніць іх выкананне. Ужывальныя ў тэстах блакавання на аснове spinlock рэалізаваны праз самаробную абвязку, якая працуе ў прасторы карыстача. Планавальнік задач можа ў любы выпадковы момант забраць кіраванне падчас выкананні гэтай абвязкі і пераключыцца на выкананне іншай задачы. Бо вымярэнне прадукцыйнасці выконваецца на падставе абсалютных значэнняў таймера, вызначаныя ў тэстах затрымкі ахапляюць не толькі затрымкі ў апрацоўшчыку блакавання, але і код, які быў выкананы ў іншым кантэксце, г.зн. вымяраюць не толькі тое, што спрабаваў вымераць аўтар тэсту, але і "шум" ад іншых вылічэнняў у сістэме.

Аўтар цеста паспрабаваў запярэчыць Лінусу, паказаўшы на тое, што ўжыванне ўласных сістэм блакавання на базе spinlock часта выкарыстоўваецца на практыцы ў гульнях, бо пры выкарыстанні прасцейшых планавальнікаў, чым у Linux, тэсты паказваюць больш высокую прадукцыйнасць. Лінус запярэчыў, што планавальнік Linux з'яўляецца ўніверсальным, навострываўся дзесяцігоддзямі і аптымізаваны не толькі для працоўнага стала і гульняў, але і для іншых выглядаў нагрузкі, напрыклад, для серверных сістэм, таму ўлічвае мноства нюансаў пры планаванні выканання задач.

Даданне спецыфічных аптымізацый, якія дазволяць зменшыць затрымкі ў гульнях Google Stadia, могуць падвысіць спагадлівасць у пэўным выпадку, але хутчэй за ўсё прывядуць да паніжэння эфектыўнасці планавальніка ў цэлым. Напрыклад, планавальнік Windows паводзіць сябе лепш у абмяркоўваюцца тэстах, бо ён значна прасцей планавальніка Linux і аптымізаваны ў асноўным для задач, спецыфічных для працоўнага стала.

Крыніца: opennet.ru

Купіць надзейны хостынг для сайтаў з абаронай ад DDoS, VPS VDS серверы 🔥 Купіць надзейны хостынг для сайтаў з абаронай ад DDoS, VPS VDS серверы | ProHoster