Автоматичний запуск програм і розпаралелювання

[Homski]

Я початківець у лінуксі, і по роботі потрібно встановити на комп лінух (більш-менш голий, так як для вбудованих систем потрібно) і зробити так щоб при вмиканні, після завантаження ядра стартувала моя програма. Що потрібно скачати - дистриьутив чи ядро (бо мене сьогодні заплутали - я думав, що дистрибутив це типу федори чи редхета, тобто з графічною оболонкою і тіпа під "вінду" з усілякими побрякушками, типу іграшок). І куда записати мою прогу і чи в якому файлі записати, щоб запускалася моя прога. А також порекомендуйте статтю чи книжку де можна більш детально це прочитати (бо мій шеф вже зібрався писати запуск нашой проги у start_kernel, а в мене таке передчуття, що так робити не слід).

Також цікавить таке питання - чи можна вказати ОС на якому ядрі процесора виконвати ту чи іншу прогу. Якщо можна то як приблизно це реалізовується і, знову ж, де про це можна детальніше почитати?

Буду дуже вдячний, якщо допоможете.

[raven]

зробити так щоб при вмиканні, після завантаження ядра стартувала моя програма

Не зовсім зрозуміло, на якому саме етапі вам треба то стартувати. Якщо зовсім відразу після ядра, то передайте ядру опцію init=/path/to/your/init. Типово це /sbin/init. Але майте на увазі - такі речі за деяких умов дуже сумно закінчуються.

Якщо ж це лише звичайний сервіс, то просто підправте стартові скрипти, щоб його запускали. Конкретний рецепт залежить від дистрибутиву.

Також цікавить таке питання - чи можна вказати ОС на якому ядрі процесора виконвати ту чи іншу прогу. Якщо можна то як приблизно це реалізовується і, знову ж, де про це можна детальніше почитати?

AFAIK в загальному випадку - не можна. Може й воно на краще, бо це зламає роботу скедьюлера. Є, правда, згадки про один експеримент - pset, але останній патч там для ядра 2.2.12, а це давно було. Здається, kernel девелопери сприйняли цю ініціативу в штики. Погугліть linux sysmp, але не думаю, що ви знайдете ще щось.

[noddeat]

AFAIK в загальному випадку - не можна. Може й воно на краще, бо це зламає роботу скедьюлера. Є, правда, згадки про один експеримент - pset, але останній патч там для ядра 2.2.12, а це давно було. Здається, kernel девелопери сприйняли цю ініціативу в штики. Погугліть linux sysmp, але не думаю, що ви знайдете ще щось.

мені щось важко придумати, навіщо це буде потрібно?
якщо у вас багатонодний кластер, то встановіть планувальник завдань типу OpenPBS.

[Homski]

Дякую.
Як я зрозумів на пряму вказати ядрам процессора, що робити неможна.
Просто тут така ситуація: по каналу Ethernet поступає інформація ( одна "порція" ~ 1 Кб, напевне це в одному пакеті буде приходити), частота з якою поступає інфо - трохи менше секунди. До того як прийде наступний пакет, треба виконати певне перетворення цієї інфо (як на мене, то ця обробка не має забирати багато часу) і відіслати далі. Спрочатку була ідея, щоб замутити 2 процеси - один займається прийомом і первинною обробкою і підготовкою даних + отримання данних з інших пристроїв, а другий - власне обробкою. Так як шеф - страшенний ретроград, то задля відстоювання паралелізму (який на мою думку, навіть без фізичного розподілення по ядрам процесора, пришвидшив би весь цей процес), я бовкнув, що "вродє має бути можливість розподілити по ядрам" (бо навіть є офтопіковий софт для кластерів який кажись це робить), тобто "прибрати" планувальник ОС і ручками вказати, що де робити (просто в нього манічка написати так ОС нічого не робила і перебрати функції ОС на себе, що на мою думку не раціонально і ГЕМОРНО).
Отже, впаховуючі ваші відповіді, наступне питання. Чи не багато процесорного часу буде з'їдати лінуховий планувальник для виділення часу процесам? І чи багато часу займає реакція ядра ОС на реагування на переривання від пристроїв (ну, наприклад, приходить пакет по сітці - спочатку ж ядро це "помічає"? - смикає ядро, а потім вже ядро віддає контроль процесу якому потрібен цей пакет)?

І про стартування. Один мій знайомий казав, що можна десь в каталозі /etc прописати щось.

На коня ще одне питання. Під словом "дистрибутив", що саме мається на увазі? Певна версія ядра з обов"язковими службами і дровами, чи пакет ОС з усілякими додатковими причандалами, типу графічних оболонок KDE, GNOME і т.д.?

[Володимир Лісівка]

Я початківець у лінуксі, і по роботі потрібно встановити на комп лінух (більш-менш голий, так як для вбудованих систем потрібно) і зробити так щоб при вмиканні, після завантаження ядра стартувала моя програма. Що потрібно скачати - дистриьутив чи ядро (бо мене сьогодні заплутали - я думав, що дистрибутив це типу федори чи редхета, тобто з графічною оболонкою і тіпа під "вінду" з усілякими побрякушками, типу іграшок).

Вам напевно потрібен дистрибутив для вбудованих систем. Голе ядро - це як голий двигун до трактора, само по собі воно не поїде. Як мінімум, потрібна libc - бібліотека, яка транслюватиме виклики системних функцій на Сі у виклики функцій ядра.

Коли ви достатньо добре знатемете лінукс, то ви самі будете здатні зібрати свій міні-дистрибутив Лінукса на основі ядра, uclibc,  та busybox (якщо захочете виконати весь цей об’єм роботи).

Я рекомендую взяти якусь подібну залізяку (роутер з Лінуксом, мобілку з Лінуксом) і подивитися як воно зроблено у них. Але не сильно переймайтеся тими маразмами які побачите - як правило такі прошивки пишуть дешеві індуси чи студіки, які в організації UNIX не розуміються абсолютно, зате добре знають маразми Вінди. :-) Рекомендую відразу взяти вільну прошивку - OpenWRT, OpenMoko, OpenEmbed, etc. - і всі сирці будуть доступні і організація дистрибутиву буде значно правильніша.

Свою програму можете записати в / sbin/init, якщо дистрибутив дуже вже обрізаний, або вказати в / etc/initrc, якщо використовувати стандартний / sbin/init. Можна також вказати ядру, в його параметрах, назву проги, яку запускати після запуску ядра. Спробуйте init=/ bin/bash чи init=/ bin/python на звичайному десктопному лінуксі, щоб зрозуміти про що я.

PS.
Просто нагадування: пам’ятайте про ліцензію - ви зобов’язані надавати джерельний текст програм під GPL кінцевому замовнику (через web чи на CD). ;-) Тому рекомендую відразу взяти повністю вільну прошивку.

[Homski]

Ну про ліцензію пам"ятаю Просто і замовники вимагають відкритий код.
Дякую за поради, подивлюся вказані дистрибутиви.

[raven]

Просто тут така ситуація: по каналу Ethernet поступає інформація ( одна "порція" ~ 1 Кб, напевне це в одному пакеті буде приходити), частота з якою поступає інфо - трохи менше секунди. До того як прийде наступний пакет, треба виконати певне перетворення цієї інфо (як на мене, то ця обробка не має забирати багато часу) і відіслати далі. Спрочатку була ідея, щоб замутити 2 процеси - один займається прийомом і первинною обробкою і підготовкою даних + отримання данних з інших пристроїв, а другий - власне обробкою.

Можна питання? Що ви будете робити, якщо до приходу наступного пакету не встигнете обробити попередній? Або якщо пакет не прийде взагалі? Ви взагалі коли-небуть чули про race conditions?

Так як шеф - страшенний ретроград, то задля відстоювання паралелізму (який на мою думку, навіть без фізичного розподілення по ядрам процесора, пришвидшив би весь цей процес), я бовкнув, що "вродє має бути можливість розподілити по ядрам" (бо навіть є офтопіковий софт для кластерів який кажись це робить), тобто "прибрати" планувальник ОС і ручками вказати, що де робити (просто в нього манічка написати так ОС нічого не робила і перебрати функції ОС на себе, що на мою думку не раціонально і ГЕМОРНО).

Скажіть вашому шефу, що він не ретроград, а некомпетентний кретин. Читати, наприклад, тут і про CFS тут до повного просвітлення. Лінки вибрав випадково, інформації в інеті на цю тему - навалом.

Взагалі-то, я можу собі уявити задачі, для яких краще написати власний скедьюлер. Але в мене нема враження, що ваша проблема до них належить.

І про стартування. Один мій знайомий казав, що можна десь в каталозі /etc прописати щось.

Стартові скрипти. Куди саме прописувати - залежить від дистрибутиву. IMO краще зробити так, ніж підміняти init. Все залежить від задач, вам краще знати.

[Володимир Лісівка]

Дякую.
Як я зрозумів на пряму вказати ядрам процессора, що робити неможна.

Та ні, можна звичайно, cирці ядра відкриті. Але навіщо воно вам? Ядро само розкине два процеси на два процесора без вашої участі.

Просто тут така ситуація: по каналу Ethernet поступає інформація ( одна "порція" ~ 1 Кб, напевне це в одному пакеті буде приходити), частота з якою поступає інфо - трохи менше секунди. До того як прийде наступний пакет, треба виконати певне перетворення цієї інфо (як на мене, то ця обробка не має забирати багато часу) і відіслати далі. Спрочатку була ідея, щоб замутити 2 процеси - один займається прийомом і первинною обробкою і підготовкою даних + отримання данних з інших пристроїв, а другий - власне обробкою. Так як шеф - страшенний ретроград, то задля відстоювання паралелізму (який на мою думку, навіть без фізичного розподілення по ядрам процесора, пришвидшив би весь цей процес),

Не факт. Під швидкістю можна розуміти як пропускну здатність так і час реакції. Пропускна здатність послідовних програм як правило вища, так як не витрачається час на перемикання контексту і міжпроцесну комунікацію. Але якщо потрібно зменшити час реакції, то потрібно робити так, щоб код, який відповідає на запити, не чекав завершення роботи основного коду. Для цього зараз не обов’язково робити паралельні програми, так як ядро у нас дуже розумне і може само прийняти пакет у буфер чи віддати з буфера.

я бовкнув, що "вродє має бути можливість розподілити по ядрам" (бо навіть є офтопіковий софт для кластерів який кажись це робить), тобто "прибрати" планувальник ОС і ручками вказати, що де робити (просто в нього манічка написати так ОС нічого не робила і перебрати функції ОС на себе, що на мою думку не раціонально і ГЕМОРНО).

http://rt.wiki.kernel.org/index.php/Cpuset_management_utility
http://rt.wiki.kernel.org/index.php/CPU_shielding_using_/proc_and_/dev/cpuset

Отже, впаховуючі ваші відповіді, наступне питання. Чи не багато процесорного часу буде з'їдати лінуховий планувальник для виділення часу процесам?

Мало. Але якщо вам потрібен hard- чи soft-real-time, то вам ядро Лінукса в чистому вигляді не підходить. Це не залежить від того, скільки часу їсть планувальник. Це залежить від того, як він планує час.

І чи багато часу займає реакція ядра ОС на реагування на переривання від пристроїв (ну, наприклад, приходить пакет по сітці - спочатку ж ядро це "помічає"? - смикає ядро, а потім вже ядро віддає контроль процесу якому потрібен цей пакет)?

Мало. :-) Але якщо вам це критично, то вам потрібно real-time ядро.

І про стартування. Один мій знайомий казав, що можна десь в каталозі /etc прописати щось.

Можна створити свою службу. Див. приклади в /etc/init.d/ . Тут трохи розписано, як воно вантажиться і де можна втикнути свою службу: http://oldfield.wattle.id.au/luv/boot.html

На коня ще одне питання. Під словом "дистрибутив", що саме мається на увазі? Певна версія ядра з обов"язковими службами і дровами, чи пакет ОС з усілякими додатковими причандалами, типу графічних оболонок KDE, GNOME і т.д.?

Під словом distribution розуміється розповсюдження збірки програм. Тобто n-ну кількість програм зібрали в одному місці і так їх і розповсюджують. Скільки програм і які вони не має значення.

[Homski]

Можна питання? Що ви будете робити, якщо до приходу наступного пакету не встигнете обробити попередній? Або якщо пакет не прийде взагалі? Ви взагалі коли-небуть чули про race conditions?

Чули, але не під такою назвою Пакет прийде обов"язково, бо приходять вони від радару, то тут питань нема (якще не приходять - це тіпа, не неаша проблема). Затримка в обробці пакетів - до 4 пакетів (це тіпа по ТЗ), якщо більше - це рівносильно тому, що воно не пахає. Військова техніка, розумієте... + Ще надходить інфо від клави, але умовно рідко.

Так як шеф - страшенний ретроград, то задля відстоювання паралелізму (який на мою думку, навіть без фізичного розподілення по ядрам процесора, пришвидшив би весь цей процес), я бовкнув, що "вродє має бути можливість розподілити по ядрам" (бо навіть є офтопіковий софт для кластерів який кажись це робить), тобто "прибрати" планувальник ОС і ручками вказати, що де робити (просто в нього манічка написати так ОС нічого не робила і перебрати функції ОС на себе, що на мою думку не раціонально і ГЕМОРНО).

Скажіть вашому шефу, що він не ретроград, а некомпетентний кретин. Читати, наприклад, тут і про CFS тут до повного просвітлення. Лінки вибрав випадково, інформації в інеті на цю тему - навалом.

Взагалі-то, я можу собі уявити задачі, для яких краще написати власний скедьюлер. Але в мене нема враження, що ваша проблема до них належить.

Як мені пояснили раніше вони робили під ДОС з одноядерним процесором. І шефу дуже подобалось те що ОС фактично "витискається"  і не приймає ніякої участі (функції ОС при цьому можуть викликатись). Фактично ОС потрібна була для того, щоб запустити прогу яку вони писали. І він хоче теж саме з Лінуксом зробити. Ядро Лінукс, як я зрозумів не витискається, воно само впешу чергу перехоплює всі переривання і розподіляє процеси. У мене мало досвіду в реал-тайм програмуванні, але на мою думку, для сучасних процесорів такі перехоплення не мають бути великою проблемою, особливо якщо процеси яким адресуються ці переривання виконуються на окремих ядрах, або просто паралельно. Я відстоюю ту позицію, що не треба мордувати себе, а користуватись тим що дає ОС - її планувальником і її обробкою переривань. Напевне, попрате мене якщо не так, планувальник в Лінуксі можна або "налаштувати" або просто взяти дистрибутив, який заточений під реал-тайм.

Дякую за посилання, читаю.

[raven]

Пакет прийде обов"язково, бо приходять вони від радару, то тут питань нема (якще не приходять - це тіпа, не неаша проблема). Затримка в обробці пакетів - до 4 пакетів (це тіпа по ТЗ), якщо більше - це рівносильно тому, що воно не пахає. Військова техніка, розумієте... + Ще надходить інфо від клави, але умовно рідко.

Здається, я розумію, про що ви говорите. Але підхід мені все одно видається дивним. Наприклад, один знайомий мені труЪ-ынтирпрайз займається обробкою, скажімо, nexrad-бюлетенів. Вони поступають ззовні. Є datastore, що приймає і складає ці бюлетені, і є клієнти, які їх собі тягають за потребою. Це забезпечує відсутність перебоїв на клієнтах і знижує їх вірогідність на датасторі практично за будь-яких умов. Все можна засетапити (датастор+клієнт) і на одній машині, звичайно. Я не вловлюю, навіщо вводити фактор часу для потенційно high-latency клієнтів. Чи то я щось не так зрозумів? Зрештою, вам видніше...

Як мені пояснили раніше вони робили під ДОС з одноядерним процесором. І шефу дуже подобалось те що ОС фактично "витискається"  і не приймає ніякої участі (функції ОС при цьому можуть викликатись). Фактично ОС потрібна була для того, щоб запустити прогу яку вони писали.

А для чого ще потрібна операційна система? Особисто мені найчудесніша ОС без програм і засобів розробки даром не потрібна=))

Ядро Лінукс, як я зрозумів не витискається, воно само впешу чергу перехоплює всі переривання і розподіляє процеси.

Ядро DOS теж якось нікуди не дівається.

Я відстоюю ту позицію, що не треба мордувати себе, а користуватись тим що дає ОС - її планувальником і її обробкою переривань. Напевне, попрате мене якщо не так, планувальник в Лінуксі можна або "налаштувати" або просто взяти дистрибутив, який заточений під реал-тайм.

І абсолютно правильно робите. Звісно, можна написати свій скедьюлер (я б таке завдання взяв, грандіозний привід для збільшення бюджету проекту з його подальшим розпилом ), але дійсно, краще бавитись в рамках існуючого. Ядро з різними конфіг CONFIG_PREEMPT (всі опції перерахувати не можу, це тільки в 2.6, а я зараз на 2.4) і man nice.

[Володимир Лісівка]

Як мені пояснили раніше вони робили під ДОС з одноядерним процесором. І шефу дуже подобалось те що ОС фактично "витискається"  і не приймає ніякої участі (функції ОС при цьому можуть викликатись). Фактично ОС потрібна була для того, щоб запустити прогу яку вони писали. І він хоче теж саме з Лінуксом зробити. Ядро Лінукс, як я зрозумів не витискається, воно само впешу чергу перехоплює всі переривання і розподіляє процеси.

Ну чому не витискається. Якщо ядро Лінукса запускати як окремий процес на якомусь мікроядрі, то воно буде працювати тільки тоді, коли йому дадуть. :-) Так реалізовані RTAI ( https://www.rtai.org/ ), XENOMAI ( http://www.xenomai.org/ ) , RTLinux, etc. Ще є можливість витісняти процеси ядра, так званий preemptive, яка є в ядрах 2.6.

У мене мало досвіду в реал-тайм програмуванні, але на мою думку, для сучасних процесорів такі перехоплення не мають бути великою проблемою, особливо якщо процеси яким адресуються ці переривання виконуються на окремих ядрах, або просто паралельно. Я відстоюю ту позицію, що не треба мордувати себе, а користуватись тим що дає ОС - її планувальником і її обробкою переривань. Напевне, попрате мене якщо не так, планувальник в Лінуксі можна або "налаштувати" або просто взяти дистрибутив, який заточений під реал-тайм.

Мені невідомі просто вимоги, але судячи з того, що система раніше працювала на старенькому процесорі, то на сучасному вона має працювати без проблем якщо вашому процесу виставити пріоритет realtime (хоча це не справжній realtime) і використовувати ядро >2.6.18 з адекватним планувальником процесів.