跳到主要內容

淺讀CuRT：task, context switch與scheduling

上一篇整理了CuRT從硬體上電後到跳入C function前所作的事情，本篇文章則會紀錄CuRT如何準備multitasking環境，以及CuRT於執行期的行為分析。

在app/shell/main.c中，我們可以看到main()的開頭為：

int main()
{
        SerialInit();
        init_interrupt_control();
        init_curt();
...

SerialInit()只是把UART port初始化，方便printf()可以正常運作。init_interrupt_control()則設定pxa255的interrupt controller可以接收外部的interrupt sources，稍後啟動的timer就會發出定期的interrupt驅動scheduling。init_curt()作的事情就比較多了點，讓我們進去瞧一瞧：

void init_curt()
{
        int i;
        for (i = 0; i < MAX_PRIO; i++) {
                prio_exist_flag[i] = false;
                init_list(&ready_list[i]);
        }
        init_list(&delayed_list);
        init_list(&blocked_list);
        init_list(&termination_wait_list);

        for (i = 0; i < MAX_THREAD; i++)
                thread_table[i] = NULL;

        is_start_os = false;
        interrupt_nesting = 0;
        os_time_tick = 0;
        current_top_prio = MAX_PRIO;
        total_csw_cnt = 0;
        total_thread_cnt = 0;
        current_thread = NULL;
        next_thread = NULL;

        /* create idle thread internally */
        thread_create(&idle_thread,
                        &idle_thread_stk[THREAD_STACK_SIZE-1],
                        idle_thread_func,
                        "idle-thread",
                        IDLE_THREAD_PRIO,
                        NULL);
}

CuRT在此處初始化task lists，不同task list代表task的狀態行為。ready_list[]表示共有MAX_PRIO個priority的ready list，每個priority會串接相同優先權的task，數字越小表示priority越高。delayed_list串接那些在等待timer喚起的task。bloacked_list則是串接等待其它resource（如：sem）釋放的那些task。接下來則是一些統計用的參數，以及幾個會影響CuRT運作的關鍵flags與物件，我們先記住它們的初始值即可，用到時再來看看行為會如何改變。接著，則是創建了一個最低優先權的task作為cpu idle時要運行的動作（等等我們就可看到，CuRT採取簡單的priority-based round robin排程策略，所以只要有更高優先權的task位於ready_list中，idle_thread就不會被執行到）。

OK，是時候觀察關鍵的thread_create()了：

/**
 * @brief Create thread
 *
 * @param thread - thread of the information contained threads structure
 * @param thread_stk - Created a pointer to the thread stack space
 * @param func - Generated a thread of the function
 * @param name - Thread name
 * @param prio - The priority of threads
 * @param pdata - Pass parameters to the function of a thread running
 * @retval RET_NO_ERR
 * @retval RET_ERR
 */
tid_t thread_create(thread_struct *thread,
                    stk_t *thread_stk,
                    THREAD_FUNC func,
                    char *name,
                    u8_t prio,
                    void *pdata)
{
        cpu_sr_t cpu_sr;
        stk_t *pstk;
        thread_struct *pthread;
        tid_t tid;

        if (thread == NULL || thread_stk == NULL || func == NULL ||
            name == NULL || (prio >= MAX_PRIO))
                return RET_ERR;

        pstk = thread_stk;
        pthread = thread;

        /* no failback */
        if ((tid = get_tid()) == RET_ERR) {
                return RET_ERR;
        }

        /* constrct thread_struct */
        pthread->tid = tid;
        pthread->stack_ptr = init_thread_stack(func, pdata, pstk);
        pthread->name = name;
        pthread->prio = prio;
        pthread->time_quantum = TIME_QUANTUM;
        pthread->delayed_time = 0;
        pthread->state = READY;

        /**
            since thread_create() might be called after OS running,
            some thread management datastructure sould be protected, here use irq & fiq disabled */
        cpu_sr = save_cpu_sr();
        thread_table[tid] = pthread;
        prio_exist_flag[prio] = true;
        total_thread_cnt++;
        insert_back_list(&ready_list[prio], &pthread->node);
        restore_cpu_sr(cpu_sr);

        /* if priority higher than existing thread, invoke the scheduler. */
        if (is_start_os == true && current_thread->prio > prio) {
                schedule(SCHED_THREAD_REQUEST);
        }
        return tid;
}

CuRT透過此function建構一個thread，使其擁有獨立的stack，在init_thread_stack()中，我們可以看到，CuRT將r0-12, r14, r15以及cpsr都給予了初始值，r13則存於thread_struct中的stack_ptr欄位。其中pc(r15)初始指向thread_func，所以一旦發生context switch時，就會跳入該function開始執行。剩下動作則是初始化基本欄位，並將task串入適當的ready_list中。最後，由於is_start_os目前設為false，所以暫且先不進行任何scheduling。

接著，我們回到main()，發現CuRT繼續串入更多task。串完後，接著就是啟動的時刻了：

void start_curt()
{
        cpu_sr_t cpu_sr;
        list_node_t *pnode;
        int top_prio;

        cpu_sr = save_cpu_sr();
        is_start_os = true;
        /* examine the highest priority thread executed */
        top_prio = get_top_prio();
        pnode = delete_front_list(&ready_list[top_prio]);
        if (is_empty_list(&ready_list[top_prio]))
                prio_exist_flag[top_prio] = false;
        current_thread = entry_list(pnode, thread_struct, node);
        current_thread->state = RUNNING;
        restore_cpu_sr(cpu_sr);
        restore_context();
}

save_cpu_sr()基本上就是讀出cpsr，同時關閉中斷，由於CuRT是由timer interrupt驅動scheduling，關閉中斷也就表示關閉CuRT主動執行context switch的動作。接下來則挑出目前ready_list[]中最高priority的ready_list中的第一個task，將其設定為current_thread，然後打開中斷（注意，此時timer interrupt仍未啟動），restore_context()負責將current_thread的context(存於current_thread的stack中)恢復：

/**
 * @brief Restore the context of the current thread.
 *
 * In multi-tasking environment, restore the context of the thread.
 * @param
 * @retval
 */
restore_context:
        ldr r4, =current_thread            // sp = current_thread->sp
        ldr r4, [r4]
        add r4, r4, #8
        ldr sp, [r4]

        ldr r4, [sp], #4
        msr SPSR_cxsf, r4
        ldmfd sp!, {r0-r12, lr, pc}^

還記得main()中開啟了哪幾個thread嗎？總共六個。包括一個idle thread與五個application threads。其中info_thread與stat_thread優先權最高（都是1），所以啟動後優先執行，而由於到此時timer interrupt都還沒啟動，所以我們可以看到info_thread與stat_thread在印出基本訊息後，都呼叫了thread_suspend()以讓出CPU，進行重新scheduling。

前兩個threads執行完後，接著優先權就輪到了shell_thread。shell_thread一開始呼叫的init_os_timer()才正式起動了preemptive scheduling的機制。從此，若有更高優先權的task被加入時，高優先權的task在被創建時（透過thread_create()），就會判斷一次是否要插入目前正在執行中的task：

tid_t thread_create(thread_struct *thread,
                    stk_t *thread_stk,
                    THREAD_FUNC func,
                    char *name,
                    u8_t prio,
                    void *pdata)
{
...
        /* if priority higher than existing thread, invoke the scheduler. */
        if (is_start_os == true && current_thread->prio > prio) {
                schedule(SCHED_THREAD_REQUEST);
        }
        return tid;
}

若沒有任何新增task，則最高優先權task則會無止盡地執行下去，直到將自己的狀態改為blocked或delayed。

timer interrupt每次起來時，ARM會自動跳轉到arch/arm/mach-pxa/start.S:

irq_handler:
        b irq_service_routine

irq_service_routine會負責將目前context存進current_thread的stack中，然後跳到interrupt_handler()中，觀察目前是否有任何delayed task是否已經可被喚起。如果可以被喚起，就會將其擺回對應priority的ready_list（此處似乎是CuRT的一個bug?因為若priority高於current_thread，應該將其替換才是。）

至此，CuRT的整體流程就差不多結束了。果然是很"輕"啊～但是能夠隨手寫出關鍵RTOS行為作為教育之用，令人獲益良多，Jserv的確是個中高手。下一步呢？試著解答師大資訊系王老師所提出的幾個問題應該是不錯的練習。:-)
標籤：

留言

張貼留言

這個網誌中的熱門文章

誰在呼叫我？不同的backtrace實作說明好文章

今天下班前一個同事問到：如何在Linux kernel的function中主動印出backtrace以方便除錯？ 寫過kernel module的人都知道，基本上就是用dump_stack()之類的function就可以作到了。但是dump_stack()的功能是如何作到的呢？概念上其實並不難，慣用手法就是先觀察stack在function call時的變化(一般OS或計組教科書都有很好的說明，如果不想翻書，可以參考 這篇 )，然後將對應的return address一層一層找出來後，再將對應的function名稱印出即可(透過執行檔中的section去讀取函式名稱即可，所以要將KALLSYM選項打開)。在userspace的實作可參考Jserv介紹過的 whocallme 或對岸好手實作過的 backtrace() ，都是針對x86架構的很好說明文章。 不過從前面兩篇文章可以知道，只要知道編譯器的calling convention，就可以實作出backtrace，所以是否GCC有提供現成的機制呢？Yes, that is what __builtin_return_address() for!! 可以參考這篇 文章 。該篇文章還提到了其他可以拿來實作功能更齊全的backtrace的 程式庫 ，在了解了運作原理後，用那些東西還蠻方便的。 OK，那Linux kernel是怎麼做的呢？就是用頭兩篇文章的方式啦~ 每個不同的CPU架構各自手工實作一份dump_stack()。 為啥不用GCC的機制？畢竟...嗯，我猜想，除了backtrace以外，開發者還會想看其他register的值，還有一些有的沒的，所以光是GCC提供的介面是很難印出全部所要的資訊，與其用半套GCC的機制，不如全都自己來~ arm的實作 大致上長這樣，可以看到基本上就只是透過迭代fp, lr, pc來完成： 352 void unwind_backtrace (struct pt_regs * regs , struct task_struct *tsk) 353 { 354 struct stackframe frame ; 355 register unsigned long current_sp asm ( "...
13 則留言
閱讀完整內容

淺讀Linux root file system初始化流程

在Unix的世界中，file system佔據一個極重要的抽象化地位。其中，/ 所代表的rootfs更是所有後續新增file system所必須依賴前提條件。以Linux為例，黑客 Jserv 就曾經詳細說明過 initramfs的背後設計考量 。本篇文章不再重複背景知識，主要將追蹤rootfs初始化的流程作點整理，免得自己日後忘記。 :-) file system與特定CPU架構無關，所以我觀察的起點從init/main.c的start_kernel()開始，這是Linux作完基本CPU初始化後首先跳進的C function(我閱讀的版本為 3.12 )。跟root file system有關的流程羅列如下： start_kernel()         -> vfs_caches_init_early()         -> vfs_caches_init()                 -> mnt_init()                         -> init_rootfs()                         -> init_mount_tree()         -> rest_init()                 -> kernel_thread(kernel_init,...) 其中比較重要的是mnt_int()中的init_rootfs()與init_mout_tree()。init_rootfs()實作如下： int __init init_root...
張貼留言
閱讀完整內容

中文試譯：Load-time relocation of shared libraries

作者： eliben 原文連結： http://eli.thegreenplace.net/2011/08/25/load-time-relocation-of-shared-libraries/ 共享庫的載入時重定位 這篇文章的目的在解釋現代作業系統如何讓共享庫在載入時的連結動作發生。我們聚焦在32位元的x86 Linux上頭，但相同的原則在其他的作業系統與CPUs上一樣適用。 要注意的是，共享庫有許多不同的名字 - 共享庫（shared libraries）,共享物件（ shared objects）,動態共享物件（ dynamic shared objects (DSOs)）,動態連結庫（ dynamically linked libraries（如果你習慣的是Windows的環境，就知道這是所謂的DLL））。為了一致性，我在整篇文章中會使用"共享庫"這個字眼。 載入可執行檔 如同其他支援虛擬記憶體的作業系統，Linux將可執行檔載入到一個固定的記憶體位址。如果我們檢視任意一個可執行檔的ELF header，我們將可發現一個Entry point的位址： $ readelf -h /usr/bin/uptime ELF Header: Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 Class: ELF32 [...] some header fields Entry point address: 0x8048470 [...] some header fields 這是由linker所放置的，可告訴作業系統要從何處開始執行此執行檔[1]。如果我們用GDB載入程式並觀察0x8048470的位址，我們將可看到.text segment的第一個被執行的指令。 這代表的是，當linker連結可執行檔時，會把全部的內部符號引用的位址都確定下來（function以及data），確定它們的固定的、最終的位址。Linker本身會對自己進行一些relocation[2]，但最終的結果不會有任何的relocation。 講啥啊？注意，我在上段文中特別強...
5 則留言
閱讀完整內容