Гледам че scheduler-а нещо взе да кляка и се оказа следната ситуация. Две ядра с отчасти споделена памет изпозлват spinlocks за да регулират, кой какво кога. Тези spinlocks регистри обаче са много кофти имплементирани и се четат/пишат през AHB/APB бъса, което е бавно - 30 такта за писане/четене/писане цикъл. Не е оптимално, но е разчетено да пасне. При профилирането се оказа обаче, че на това място се губят не 30, а 70-80 такта. Допълнителните 40-50 такта идват от викането на функцията в драйвера:

* 20 такта от загубата на pipeline-a
* 30 такта от window handling-а, особено като натрупа call depth

Предполагам най-лесно би било да се дефинират функциите inline. Обаче се викат от 1000 места в кода, което ще изяде много IRAM.

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

*запомни къде си
*скочи на макроса
*изпълни макроса (пиши/чети/пиши spinlock регистъра през AHB/APB бъса) - друго няма
*върни се там от където си дошъл

Знам че на макросите се гледа лошо, но ако гарантирам че AHB/APB бъс аксеса не бърка нищо по вътрешните регистри би трябвало да е сигурно. Мнения?

нямаше да е зле да уточниш типа на ядрата... все пак AHB се ползва в различни архитектури, а някои имат и други средства за синхронизация

Компилаторът също ако не е тайна... за GCC може да си инлайнваш, а може да си направиш операцията на асемблер и да си я ползваш където ти трябва... Но и за другите компилатори има такива неща обикновено, така че малко не е ясен въпроса ти

Е той въпросът е по-скоро теоретичен - може ли inline без да яде допълнително памет или по-скоро за какви мотики да се подготвя... Ядрата са напълно къстъм, а компилатора е адаптиран GCC.

С какво макрос, който има запомняне, скачане и връщане , се различава от функция?

GCC може много неща, но не става ясно ти какво искаш...

Идеята на инлайнването е викането на функция да се замени със самата функция. При GCC e желателно да ползваш static inline така ще може да се прескочи ограничвението на каквато там calling convention се ползва и всяка инстанция да се оптимизира индивидуално.
При всички случаи обаче, инлайна ще накара кода да набъбне, освен ако функцията ти не е само от една инструкция.

Другия вариант е викане на функция, т.е. скачане на адреса на функцията, изпълнение и накрая връщане кой откъдето е дошъл. Ако щеш ползвай макроси, ако щеш недей, но те са нещо дето предпроцесора ще разкара още преди да е почнала компилацията. В крайна сметка в кода ще имаш или викане на функция, или тялото на функцията. За среден вариант не съм чувал

Това си е класически function call. Според каква ви е къстъм архитектурата това може да е ефективно или не. Например в x86 запомни къде си е запис в стека и т.н. което я е кеширано я не т.е. не е много ясно колко такта ще коства. При АРМ пък върхът на стека е в един от регистрите и компилаторът услужливо го е запазил ако знае, че ще се викат други функции - спинлок би трябвало да не вика други функции, така че при арм ще е сравнително ефективно - разбира се и там пайплайна може да се наложи да се презарежда и т.н. Т.е. ей така без да се знае архитектурата едва ли някой ще може да даде обоснован съвет. Ако е възможно покажи някакъв дизасм на тази спинлок функция - би могло много да се оптимизира за да олекне викането и. Понякога дори безумни на пръв поглед неща помагат - например преподреждане на аргументите за да не се налага компилатора да генерира код да ги нарежда при всяко извикване и т.н.

С макроси може и да се докара среден вариант - ако макроса генерира инлайн функция и вкарва в нея код който му е подаден като параметър тогава според кода функцията може да мине критериите за инлайнване или да не ги мине. Не знам дали ми се разбира писанието - обикновенно това са неща които не трябва да се правят. Опре ли се до микро оптимизиации коня вече е отишъл в реката ...

stefan63 отличен въпрос. Идеята ми е да го направя така, че да се различават. Т.е. ако макроса няма влияние върху run time environment няма да се обвърже с недостатъците на функцията. Как обаче да стане това при наличието на два параметъра - идентификатора на спинлока и адресът от който идвам. И тук врътката е даразширя архитектурата с един "скрит" 32 битов регистър, който да пази параметрите. Този регистър няма да се ползва за друго и следователно няма да е част от rte и ще ми спести мятането по стековете и набъбването на IRAMa...

То че са микро оптимизации, микро са. Но ако това позволи да се смъкне клока с 2-3% си струва. Борбата е за всеки uA

Много сложни неща правиш.
Тоест - ако имаш инструкция от вида
mov32bit &spinlockplaceinmemory, #newvalue
може би ще спестиш нещо?
Не става ли с някой юзер флаг в статус регистъра,ако има де?

HCL май имаш нужда от малко почивка

Остави макросите на мира, те нямат отношение... твоето ядро не изпълнява макроси, а код. Да буташ инструкшън сета заради спинлок е тъпо. Що само спинлок функциите да са бързи? Трябва всички да са бързи...
Ако ще правиш нещо къстъм за синхронизация, то обикновено се прави snoop control или нещо друго на тема cache coherency, така че двете ядра (или повече) да могат да си бъбрят бързичко и директно. Тия 20-30 клока за една RMW операция миришат на издънка... А пък да клекне scheduler заради синхронизация (каквато и да е тя) значи нещо генерално е сбъркано

@HCL: И аз не разбрах "макроси" в какъв смисъл го употребяваш.

Подходите ти може да са:

1) Custom инструкции за spinlock-ове, евентуално микрокодирани.

2) Ако ядрата имат кешове, нещо от рода на LL/SC.

3) Синхронизирането да не минава през AHB.

С тия прозорци да не е нещо SPARC-оподобно?

@miro_atc защо да е тъпо да се бута инструкшън сета заради спинлок? Идеята на къстъм архитектурата е да бъде напасвана към особеностите на FW-а. Актуално спинлоковете се ползват често. Aко се появят други функции, който оказват влияние и за тях ще оптимираме. 30-е клока определено са издънка, просто досега не се е налагало ядрата да имат ускорен достъп до шините тъй като всичкото им комуникация с външния свят се осъществава чрез интеръпт контролери и вързани за DRAM-а DMA engines. Сега това се променя и затова напасвам.

А относно клякането на scheduler-a, ако няма такова значи правим нещо грешно. Идеята е, че в чипа има една камара ядра и поне 10 пъти повече хардуерни оскорители. Системата е hard real-time, за 1мс трябва да се свърши сума ти работа. Тази е разделена между ядрата и ускорителите. В зависимост от конфигурацията, някои ускорители и ядра получават по-голям времеви прозорец, други по-малък. Накрая всяка свободна микросекунда се анализира и при възможност се намалят съответните частоти. Много често по-ниските частоти означават и по-ниско напрежение и това оказва значително влияние върху консумацията. Като резултат, в зависимост от конфигурациите, някои ускорители/ядра биват забързани (race to idle), а други забавени (slow for Vlow). Резултатът е един адаптивен scheduling стремящ се към оптималния режим или моментът на клякане.

@woody решението накрая май ще са микрокодирани спинлокове + "скрит" регистър. Така ще избегнем както AHB трафика и function call-овете в драйвера. На това място кешове няма, архитектурата е RISC, но не е SPARC, а ядрата са по 100-200 хиляди гейта.

Това, което разбрах от обясненията ти е, че имаш бавен интерфейс. Ако това е проблем, той няма как да бъде решен с промяна на инструкции. Интерфейсът пак ще си е бавен.
Най-много да си вкараш автогол, особено ако тая поредица може да бъде прекъсвана и някой да ти направи task switch по средата...



Може и аз да не съм разбрал, но останах с впечатлението, че кляка от много синхронизации. Което би било абсурд, понеже независимо дали си или не си реал тайм, преди всичко имаш ядро, което трябва да върши някаква полезна работа. Времето, което един проц отделя за да изпълнява тая полезна работа, спрямо времето което губи за синхронизации и други сервизни функции в общия случай трябва да е под 1%. Ако е повече от това, значи може да се замислиш дали нещо не е сбъркано в картинката. Ако е по-малко пък, няма как нещо с под 1% CPU usage да те събаря. Още повече в реал тайм система.
И като стана дума за реал тайм, надявам си наясно че има лимит до който може да сваляш честотата. Точната стойност зависи от шедулинг алгоритъм, но в масовия случай за RMA е 69%. Демек ако допуснеш над 69% CPU usage вече ти носиш отговорност за реал тайма, а не шедулъра... Разбира се, ако имаш някаква хитра системка за мигновена смяна на клока може да си го клатиш както искаш, но тогава няма нужда от "адаптивност", просто проца спи докато няма работа (wait for interrut/event...).

Интерфейс-а е бавен, но целта е вместо до го ускорявам да избегна напълно необходимостта от него в тази ситуация.

За броя на синхронизациите си прав и картинката е напълно сбъркана, но този проблем се решава в друг проект. Работата е такава, че в ASIC бизнеса когато решаваш дали да дялкаш наново чипа или да напаснеш леко някои стар за ново приложение много често е въпрос който се решава във финансовото отделение, а не в инженерното и се налага да работим с каквото имаме. Просто RND разходите са убийствени.

А честота, както и напрежението се сменя динамично, без това сме за никъде. Приспиването на проца като няма работа беше валидно до един process node, надолу си трябва адаптивност както в scheduler-а на ядрата, така и в този за акселераторите.

я обясни какво точно синхронизираш?
Имаш 2 (или повече) ядра и критични секции, в които искаш само един да бара в даден момент?