Срещу време се намали времето за реакция приложение в Linux

Какво сме ние?

Работа на компютър, ние постоянно се сблъскват с различни видове закъснения. Опитайте и двете ядро ​​Кампильо, да слушате музика, да изтеглят филми по мрежата и задавайки OpenOffice.org. Сигурен съм, че рано или късно ще се изправи пред факта, че в Writer знаци ще се появят след няколко секунди, след като натиснете бутона на клавиатурата, и играчът постоянно ще заекването. Как е възможно да се намали времето за реакция на приложения за Linux - операционната система на разпределение на времето. където всички процеси са равни (е, почти)? В крайна сметка, той е разработен с фокус върху оптимизиране на производителността на системата като цяло, както и за ограничен период от време се гарантира, приложения за реакция
вън от въпроса.

Ние използваме средствата, с ръка

Както е известно, в системата на живота идва от процесите, които играят ключова роля във всяка операционна система. Гумени ядро ​​не е, и въпреки прекомерен гигахерца честота за единица време може да изпълни указанията на само един процес (кванта време се нарича усвояване процесор), и може да бъде много много процеси в себе си система. Така че, за да се намалят закъсненията, броят на процесите трябва да бъдат сведени до минимум. За да направите това, трябва не само да премахнете всички ненужни програми и деактивирайте всички неизползвани демони, но също така и за възстановяване на ядрото, оставяйки само наистина необходимо функционалност.

С цел да се отделят средства за културно и никой в ​​същото време да не се лиши, във всяка система има своя собствена подсистема за контрол на процесите. Тя работи на принципа "на всекиго според способностите, на всеки според делата му". Процесът може да се управлява в два режима: Ядро на режим (режим на ядрото) и в режим на потребител (потребителски режим), където той изпълнява прости инструкции, без да се изисква специални данни "система". Но когато са необходими такива услуги, процесът влиза в режим на ядрото, въпреки указанията ще продължат да се извършват от името на процеса. Всичко това се прави нарочно, за да защити ядрото работното пространство на процеса на употреба. Други методи за получаване или
пускането на пазара, в очакване на планировчика ги избира, или са в режим на сън (спи), в очакване на недостъпна в момента ресурса от време. С прости на последния. Когато един сигнал от контролирано устройство, процесът се обявява TASK_RUNNING и се нарежда на опашка готов за пускане. Ако тя има най-висок приоритет, ядрото превключва на неговото прилагане.

Но има и друг zakovyrka. При предоставяне на процеса на системни ресурси възниква т.нар контекст превключвател (превключване на контекста), запазване на имиджа на текущия процес (който, между другото, също се изисква известно време, така че латентността дори и в идеалния случай, ще има нула). Така че контекст ключа, когато един процес е в режим на ядрото може да доведе до рухването на цялата система. Затова процес с висок приоритет ще трябва да изчака търпеливо момента на преход в режим на задача, и това може да се случи в два случая: работата се извършва или изисква ресурс не е наличен. Това означава, че е необходимо да се намали броят на ядрената да се осигури бързо време за реакция
задачи. Но за такова решение, за да плати на цялостната стабилност и "тежестта" на код. Микрокърнъла е, между другото, се продават много по-добре - там е основен минимален набор от модулни друго висеше като коледна елха, която осигурява гъвкавост и ви позволява да се изработи система за конкретни задачи.

По отношение на процесите на планиране, тя е свързана с приоритета. Scheduler просто избира следващия процес с най-висок приоритет. В този случай, по-нисък приоритет процес работи в даден момент, може би дори не е напълно изпълнява своята квантова до края. Всеки процес има два вида приоритет: Относителни (p-> хубаво, приоритетни нива за неизпълнение 100 на), инсталирани при стартиране на приложения и токът на базата на който се среща график. Стойността на настоящия приоритет, не е фиксирана, но динамично изчислява и зависи от Ница. Стойността определен от потребителя, може да бъде в диапазона от -20 до 19, за прилагане с
по-висок приоритет стойност съответства на -20 и 10 (по подразбиране) и по-горе, се счита, че има по-нисък приоритет задачи. Например, за да стартирате програмата с по-високо от нормалното приоритет, направете следното:

$ Sudo хубаво --20 MPlayer

По-ниска:

$ Sudo хубаво -20 работа

За смяна на относителния приоритет на един процес, трябва да използвате идентификатора на процеса, а не име:

$ Sudo renice --20 PID

Текущ приоритет зависи от времето прекарано и системни ресурси. Той се преизчислява всеки тик и по време на изход от режим на ядрото. В различни системи, това се случва в техните формули, в най-простия случай, приоритет е разделена на две, а когато се изчерпи напълно преизчислява (възстановен). Този механизъм позволява да получите вашето време и с нисък приоритет приложения, но в края на краищата високия приоритет, получи голямата част от него.

Всички тези тънкости, се използват в най-различни кръпки за изпълнение ядрото lowlatency на 2.4. Заменен не само приоритет на сегашните алгоритми за реализация, но всичко е възможно постоянно (например, хубаво лимит е увеличен до 256), в допълнение, таймер се настройва с честота до 1000 Hz. Пример за такова решение ще намерите на страница www.zip.com.au/

За да се укаже на заявлението, което изисква специално внимание от страна на процесора може да се използва и да се включат в POSIX спецификации в реално време, обадете SCHED_FIFO (нещо като преход към "мека" режим на реално време). Подобен резултат се постига чрез използване SCHED_RR разговори, CAP_IPC_LOCK, CAP_SYS_NICE или чрез смяна на ценностите sys_sched_get_priority_max - функция, която връща максималната приоритет в реално време. Тя е използването SCHED_FIFO причинява че XMMS играч да се движат при корена, почти заекването дори при извънредно високи натоварвания на системата.

разтоварване на ядрото

Основният проблем на реално време, е възможността за заснемане на ресурси от най-ниския приоритет процес. особено ако тя работи в режим на ядрото. В крайна сметка, дори и в превключването на контекст прекара известно време. Стотици разработчици по целия свят са се опитали да използват милиардите технологии: възможността за прекъсване по време на изпълнение в режим на ядрото (търпящи изпреварване ядрото, ядрото се разтоварва) до временна наследство (наследява) приоритет в реално време на прилагане на ниско-приоритет. така че да може бързо да приключите критична част от кода и да даде контрол.

Тема пейджъра ядрото на съответното лице в периода на господство на 2.2 клон обществеността. Линус Торвалдс заяви, че в реално време - лоша идея, а за да бъде търпящи изпреварване време стана ясно, само с помощта на лепенки. Но в подготовката на възможност да се разклони ядро ​​2.6 разтоварени (PREEMPT_RT) е добавен в изходния код. Търпящи изпреварване-ядрото се изпълнява, обикновено под формата на второ ядро. Ако процесът се обръща към него с молба, основната система всъщност е блокиран по време на неговата екзекуция. Извършва се всичко това като достъпен за изтегляне модул, който замества / прихваща най-критичния функция, която може да доведе до забавяне. Но не всичко е толкова просто. В интервю за един
MontaVista на инженерите (компанията-разработчик на едно от решенията за реално време на базата на Linux) каза, че в 2.6 ядро ​​около 11,000 парчета код е просто невъзможно да се направи, търпящи изпреварване.

На интернет, ако е добра търсене, можете да намерите достатъчно на брой различни лепенки, които позволяват да се приложи в реално време Linux, но, като правило, по-голямата част от проектите вече са остарели и предлага промени в ядрото 2.4. Например, KURT-Linux (www.ittc.ku.edu/kurt) и RT-Linux (www.rtlinux.org). И двете Linux се използва подобна технология, и субективни разлики в тяхната работа не се забелязва, но в интернет похвали от всички и разни е RT-Linux. Намери компютри под негов контрол е достъпен на генератори "Токамак", в Перу, болници,
сателити на НАСА в симулатор F111-C. Между другото, ако Ubuntu влиза Sudo търсене ап-кеша в реално време, а след това ще откриете присъствието на пакета със стария 3.1pre3-3 версия на RT-Linux.

ядрото лепенки

На стандартното ядро ​​стартиране на RT-тест полезност. Само тичане, получаваме стойност от 0,125 милисекунди, когато натоварването се увеличи, тя увеличава до 15.402 мс. Обърнете внимание на определяне на критерии, което е равно на 100 микросекунди. В този случай, резултатът от теста - FAIL, а именно, в реално време все още е далеч. Сложете lowlatency-ядрен - общо ядро, но с таймер 1000 Hz и намалено време за реакция:

$ Ап-да инсталирате Linux-lowlatency

Рестартирайте и стартирайте RT-теста отново.

$ Sudo RT-тест на всички

Стойността на старт сега равна на латентността на 0.073 милисекунди, а максималният - 2907 милисекунди. Това е по-добре. Въпреки критерии не е, но Muzychko в Amarok'e вече не прекъсва при прилична обувка.

От всички на изпълнението на реално време, системи за вземане на само един дойде днес, предлагани Инго Molnarom. Носеха се слухове, че кръпките (www.kernel.org/pub/linux/kernel/projects/rt), издадени от него ще бъдат включени в ядрото 6.2.22, но докато това се случи. За да инсталирате Fedora RT фенове просто въведете Yum инсталирате ядрото стайна температура, други ще имат малко pokompilirovat. Изтеглете и прилага кръпка на ядрото:

$ Wget -C www.kernel.org/pub/linux/kernel/projects/rt/older/patch-2.6.22.1-rt9
$ Tar xjvf Linux-2.6.22.1.tar.bz2
$ Cd Linux-2.6.22.1
$ Sudo кръпка -p1 <. /patch-2.6.22.1-rt9
$ Направи menuconfig

След рестартиране на системата, чрез въвеждане на dmesg, можете да видите, че ядрото е замествам RT. таймер часовник е нестабилна ( «Clocksource TSC нестабилна») и PS AUX показва наличието на голям брой нови процеси. Но ние сме по-заинтересовани от резултата от RT-теста. Така че всички наши трикове са довели до това, което сега максималната латентността е по-малко от 0,07 милисекунди. Voila, тест премина!