User Adjustable Process Scheduling Mechanism for a Multiprocessor Embedded System

Transcription

1 Proceedings of he 6h WSEAS Inernaional Conference on Applied Compuer Science, Tenerife, Canary Islands, Spain, December 16-18, User Adjusable Process Scheduling Mechanism for a Muliprocessor Embedded Sysem SLO-LI CHU, CHIH-CHIEH HSIAO, PIN-HUA CHIU, HSIEN-CHANG LIN Deparmen of Informaion and Compuer Engineering Chung-Yuan Chrisian Universiy 200, Chung Pei Rd., Chung Li, 32023, TAIWAN Absrac: The muliprocessor compuer sysems become more popular for he improvemen of he processor s design and fabricaion s evoluion. In he pas, he muliprocessors sysems are usually adoped in server sysems. Nowadays, he configuraions of muliprocessor are also adoped in he personal compuers or embedded sysems. Bu we canno achieve he opimal performance of he muliprocessor sysems efficienly because ask-scheduling mechanism canno be adjused for he real performing siuaion. Even he ask-scheduler of he operaing sysem canno handle his problem. Also, he parallel program is hard o develop for he specific sysem o improve performance. In his paper, we provide a ool, called MONOPOLY, for users o adjus he scheduling policies of OS dynamically. I can improve he uilizaion of he muliple processors resources by allowing user o occupy a processor o make he specified program execue solely. In our experimen, he resuls show ha he program will finish faser by using MONOPOLY. When he sysem is fully loaded, he execuion ime of he program wih MONOPOLY will be much shorer hen he program wihou his ool. Key-word: MONOPOLY, Muliprocessor, User Adjusable Process Scheduling, Operaing Sysem, Embedded Sysem 1 Inroducion Embedded Sysems become more popular, such as he mobile phone, MP3/MP4 player, and indusrial compuers. As we know he embedded sysems, which are design for some specific applicaions. Accordingly, he designers usually wan o reduce he coss by limiing sysem resources. However, he embedded applicaions become more complex. So he performance of he embedded sysem should be enhanced by some echniques, even by adoping SMP archiecures. Symmeric Muliprocessor, or SMP, is a muliprocessor compuer archiecure where wo or more idenical processors are conneced o a single shared main memory. Mos common muliprocessor sysems oday use SMP archiecure. SMP sysems allow any processor o work on any ask no maer where he daa for ha ask is locaed in memory; wih proper operaing sysem suppor, SMP sysems can easily move asks beween processors o balance he workload efficienly. However, he increasing of processors are no always bring large performance enhancemen. If we observe he ask execuion in he SMP sysem, he workload of each processor is no always balanced; some processor will go ino idle. However, if we ry o fully uilize he processors he program mus be designed in parallel. When develop he parallel program, we need o consider he programming syle of parallel processing or adop some parallelizing compiler o ransfer program. In fac, he sofware indusries are lake of sandard ools o opimize he program for each muliprocessor sysem auomaically. By he way, he operaing sysem generally use firs processor o handle inerrups, so he scheduler will schedule he process o he firs processor generally, only when he workload of processors are very imbalanced. This will causes he imbalanced workload and reduce sysem uilizaion. Today, he rends of processor s design have been moved from developing higher frequency o reduce power consumpion. In order o achieve high performance and low power consumpion, he sysem archiecure obviously change from higher frequency o muli-core processor, even in embedded compuing. In many applicaions of embedded sysems, more and more applicaions focus mulimedia encoding/decoding, like 3G mobile phone and video camera wih MPEG-4 feaures. They need powerful compuaion capabiliy wih small scale, high performance, low-power consuming, and reliable compuaion. According o hese requiremens, he muli-core or chip muliprocessor archiecures seem o be he bes answer. Therefore we develop a ool, called MONOPOLY, o fully uilize he capabiliy of muliprocessor sysem according o acual user requiremen. I allows user o adjus he scheduling mechanism of operaing sysem for he specific program so he program can be performed solely and finish faser on he muliprocessor sysem The organizaion of his paper is as follows. In secion 2, he previous scheduling mechanism of Linux kernel and

2 Proceedings of he 6h WSEAS Inernaional Conference on Applied Compuer Science, Tenerife, Canary Islands, Spain, December 16-18, relaed sudy are reviewed. Secion 3 presens he implemenaion of our MONOPOLY sysem in deail. In secion 4 we demonsrae he experimenal resuls and he speedup obained when MONOPOLY is used. Finally, secion 5 and secion 6 give he conclusion and fuure works respecively. 2 Relaed Works 2.1 Inroducion o Linux kernel scheduler There is a brand new schedule mechanism in Linux kernel 2.6[1][2][4][5][6], which can finds he mos suiable ask o execue in he mos siuaions. When a program is execuing and enering he scheduling, his ask will be puing in he corresponding prioriy s runqueue. In a period of ime, imer inerrup will rigger schedule() o check he ime slice of curren asks is running ou or no. If yes, schedule() will find he nex execuing asks from runqueue. According a normal queue, if here is a ask running ou is ime slice, i will be removed from he head of queue o he ail of queue. Cause a leas O(n) ime complexiy, for he needs of decreasing re-calculae loops. The scheduler mainains wo prioriy arrays: acive and expired for each processor. The acive array keeps he asks ha haven run ou of is ime slice. And in expired array, includes he asks ha have run ou of is ime slice. Time slice will re-calculae when a ask runs off is ime slice before moving o expired array. Acive array and expired array will be exchanged while all of he asks in acive array run ou is ime slice. sruc runqueue{ sruc ask_sruc *curr; //curren array sruc ask_sruc *acive;//acive array sruc ask_sruc *expired; //expired array }; The srucure of he prioriy array And schedule() can easily find nex highes prioriy asks by he saemens below. sruc ask_sruc *prev, *nex; sruc lis_head *queue; sruc prio_array array; in idx; prev = curren; array = rq->acive; idx = sched_find_firs_bi( array->bimap); queue = array->queue + idx; nex = lis_enry(queue->nex, sruc ask_sruc, run_lis); The Fig.1 shows how he scheduling mechanism works. Firs, schedule() calls sched_find_firs_se() o find he firs bi in acive array, and his bi corresponds o highes prioriy and execuable ask. Then his ask will be execued by processor. Execuing ime of hese saemens doesn influence on he number of asks in he sysem i s O(1). schedule() bi-0 : Prioriy bi Prioriy Array While Linux kernel manages a SMP sysem, every processor has is own runqueue. Besides, wihin fix laency, he kernel has o check amoun of asks running on each processor is balance. If no, load_balanced() will move asks beween processors o make balanced workload. 2.2 ARTiS ARTiS is a real-ime Linux exension ha arges SMP. The goal of ARTiS (Asymmeric Real-Time Scheduling) Projec [3] is acceleraing real-ime asks response laencies. RT0 means hard real-ime which needs o be done as soon as possible, and RTn is sof real-ime. When ARTiS is booing, all of he processors will be pariioned ino wo pars RT and NRT. RT processors are specialized o execue real-ime asks, and NRT processors are specialized o execue non real-ime asks. The Fig.2 and Fig.3 show he difference beween he real-ime scheduling policies of Linux and ARTiS RT Task sched_find_firs_se() RT Task bi-7 : Prioriy 7 bi-139 : Prioriy 139 Prioriy 30 Prioriy 11 Prioriy 9 Prioriy Prioriy The processes of prioriy 7 Firs process in runqueue Fig. 1. The schedule mechanism of Linux kernel 2.6 RT Task Fig. 2. The original scheduling mechanism of Linux kernel.

3 Proceedings of he 6h WSEAS Inernaional Conference on Applied Compuer Science, Tenerife, Canary Islands, Spain, December 16-18, NRT CPU RT CPU RT Task RT Task RT Task Task 0 Task 2 Task 3 Task 5 Task 1 Task 4 Fig. 3. The scheduling mechanism of ARTiS When ARTiS is sared, all of he RT asks will be arranged o RT processor, and NRT asks will be moved o NRT processor. When here is a free RT processor, NRT asks will be moved o RT processor. In oher condiion, while he number of RT asks is larger han RT processors, hose RT asks ha haven occupied processor will be arranged o NRT processor by ARTiS load balancer. And Linux will follow he original mechanism when execuing NRT asks. ARTiS, using a ask FIFO o save he moving asks in sead of locking wo runqueues o diminish laencies during moving asks beween NRT processor and RT processor. If RT processor is fully loaded and here is a RT ask waiing for execuion, he RT ask will be moved o NRT processor. When here is free RT processor, he RT ask will move o RT processor hrough he ask fifo. So ha wo runqueues do no need o wai for spin lock. Make he arrangemen for RT asks more efficienly in muliprocessor sysem. 3 Implemenaion In his paper, we bring up a mechanism. When he mechanism sared, he program, which is seleced by user, can occupy he seleced processor. The Fig. 4 and 5 show he mechanism we wan o implemen. Task 0 Task 1 Task 3 Task 4 Task 2 Task K Task 3 Task 4 Tasks migrae o CPU 0 only Task K on his CPU Fig. 4 A snapsho of a ypical ask scheduling Task 5 Fig. 5. When he Task K is execuing via our ool When mechanism sared, he asks will be removed from processor 2 o processor 1, hen pu ask K o processor 2 as Fig. 5. From now on, every ask can be arranged o he runqueue of processor 2. Bu processor 2 follows Linux mechanism while our mechanism isn sared. This ool needs o move asks beween processors. So we need o modify he kernel o mees our requiremens. According o our code racing, we ge he following siuaions ha kernel will move asks beween processors. scheduler_ick() schedule() idle_balance() rebalance_ick() migraion_hread() idle_balance_newidle() load_balance() move_asks() move_asks() acive_load_balance() move_asks() pull_ask() pull_ask() pull_ask() migrae_ask() Move ask off curren CPU o desinaion CPU Fig. 6. The call graph of asks movemens

4 Proceedings of he 6h WSEAS Inernaional Conference on Applied Compuer Science, Tenerife, Canary Islands, Spain, December 16-18, In scheduler_ick(), if schedule() found ha if a processor is going ino idle, he scheduler will call idle_balance() o pull he asks from oher processors o preven from unbalanced siuaion. And he rebalance_ick() will check he load-balance beween processors via rebalance_ick(), if he he load is no balance, he load-balancer will adjus he loading o be balancing. The migraion_hread() is a special kernel hread, every processors have such kernel hread. In he Linux 2.6 sysems, we can find his process exiss wih he name migraion/n. I is used o move hreads beween processors. If we wan he loading be unbalanced. We mus ry o preven he asks movemens in hese load balance funcions. And ry o occupy one of he processor. These cause los of code modify o he linux kernel. Bu in Relaed Works, we menioned here s a research abou enhance he Real-Time performance of he sysem, ARTiS. The ool used in his paper is based on ARTiS Projec ha menioned in Relaed Works. User only needs o selec a program and which processor will execue his program. This ool will modify he aribue of he ask o mee ARTiS s requiremen. To make he ask o be RT0 prioriy o occupy specific processor, we can se ask as RT0 by he saemens below. #include <sched.h> //declarae of scheduling policy sched_param schp; //ge maximum prioriy (RT0) schp.sched_prioriy = sched_ge_prioriy_max(sched_fifo); //se scheduling policy for he process sched sescheduler(0, SCHED FIFO, &schp); Besides, use he following saemen o se which processor will be occupied by he ask. #include <sched.h> //declarae of specific CPU unsigned in spec_cpu; //se he CPU affiniy for he process sched_seaffiniy( 0, sizeof(unsigned long), 0x1UL << spec cpu); The wo seing procedures ransfer he seleced program o RT0 i.e. i will occupy a seleced processor. And he oher asks will be arranged o oher processors. And his characerisic is perfecly mees our needs. Making he users can adjus processes scheduling mechanism easily via our ool. 4 Experimenal Resuls We verify our firs version of ool on x86 plaform. We use Fedora Core 3 ( Linux kernel wih ARTiS ) as operaing sysem and GCC 3.4 as compiler. The hardware seings are Penium D 2.8GHz, 1GB DDR SDRAM wih Inel 945G chipses. The sofware o exam execuion ime is he MP3 converer LAME and MPEG encoder/decoder MPlayer. We use LAME o conver wave file o mp3, MPlayer o conver MPEG-1 video o H.263+ MPEG-4 Video. When he es is running, we will also run some applicaions o ensure here are some loadings on he sysem. Noe ha he wave files in he es are 16-bi 44.1KHz forma and he MPEG-1 video file is in 320x240 resoluion wih 29FPS. 4.1 The sysem wih ligh loading We re running X-Windows (GNOME 3.x) and MPlayer o play an MPEG-1 video. Compare he execuion ime of compressing differen sizes of wave files by LAME. (Argumens of LAME: -b 320) Table 1. Using LAME o conver wave o mp3. Wave file o es Time (sec) 40MB 100MB 400MB Linux Wih Tool Difference % 10.1 % 10.8 % From Table 1, we can find if he program execue via our plug ool, he execuion ime is obviously decreasing. We can conver he wave file o mp3 files faser, as he file become larger he incremens of execuion ime is more and more obvious. When he file size comes o 100MB, he improvemen of execuion ime can reach 10%. Nex, we compare he execuion ime of he compressing MPEG-1 video file o H.263+ MPEG-4 video file via MEncoder in MPlayer. We use he 2-pass encoding mode, o conver he MPEG-1 file o H.263+ MPEG-4 file.

5 Proceedings of he 6h WSEAS Inernaional Conference on Applied Compuer Science, Tenerife, Canary Islands, Spain, December 16-18, Table 2. Conver 50MB MPEG-1 Video file o Time (sec) Pass-1 Pass-2 Toal Linux Wih Tool Difference % 24.7 % 26.1 % Table 3. Conver 350MB MPEG-1 Video file o Time (sec) Pass-1 Pass-2 Toal Linux Wih Tool Difference % 29.7 % 30.5 % From he Table 2 & 3, we can find when he program execues via our ool. The execuion ime of he programs is improved a lo. 4.2 The sysem wih higher loading As above, he X-Windows and he MPlayer o play an MPEG-1 video, we also open anoher MPlayer o play an video in X-Windows sysem. Table 4. Using LAME o conver wave o mp3. Wave file o es Time (sec) 40MB 100MB Table 5. Conver 50MB MPEG-1 video file o Time (sec) Pass-1 Pass-2 Toal Linux Wih Tool Difference % 30.6 % 32.0 % Table 6. Conver 350MB MPEG-1 video file o Time (sec) Pass-1 Pass-2 Toal Linux Wih Tool Difference % 36.2 % 36.0 % Comparing he resuls above and he resuls wih he sysem of ligh loading, we can find ha he improvemens of execuion ime are increased more han before. Take LAME for example, he execuion ime of his resul can improve more abou 8% and he convering of H.263+ is abou 6% Time of Ligh Loading Sysem Linux Wih Tool Difference % 18.3 % sec 0 40MB Wave 100MB Wave 50MB MPEG-1 Tesing Files 350MB MPEG-1 Linux Wih Tool Fig. 7. Experimenal resuls (Ligh loading sysem)

6 Proceedings of he 6h WSEAS Inernaional Conference on Applied Compuer Science, Tenerife, Canary Islands, Spain, December 16-18, sec Time of Heavy Loading Sysem MB Wave MB Wave MB MPEG-1 Tesing Files MB MPEG Linux Wih Tool Fig. 8. Experimenal resuls (Heavy Loading Sysem) Fig. 7 and Fig. 8 compare he experimenal resuls. As we can find in he bar chars, he execuion ime is significanly decreased wih our ool. All he resuls showed ha if a program execued wih our ool, he execuion ime would be less hen he original OS scheduling mechanism. 5 Conclusions In he paper, we provide a mechanism for user o adjus scheduling mechanism of he operaing sysem, which allow a seleced ask o increase execuing speed by occupy a processor solely. From experimenal resul, we can make grea speed enhance by leing a ask occupy a processor. While he sysem is high loaded, a RT processor can concenrae on execuing he seleced ask insead of serving many asks wih conex swiching. Oherwise he seleced ask will be scheduled wih oher asks and wase ime cones swiching, and hen he seleced ask needs more ime o be finish. Today, he muliprocessor archiecure becomes more and more popular, bu i s sill a difficul opic o fully uilize he resources of processors effecively. Also, he operaing sysem canno assign he resources properly and i s hard o design a parallel program. So develop a user adjusable dynamic scheduling mechanism ha can assign a ask o a specified processor and execue solely is very helpful, no only accelerae execuing speed of he seleced ask, bu also increase he uilizaion of processors. Muli-processor becomes mainsream in he erriories of server and personal compuer. Bu embedded sysems do no have rapid compuaional abiliy as servers and personal compuers. So he resources of processor are more precious in embedded sysems. We can uilize resources more effecive in embedded sysem by user adjusable scheduling o enhance efficacy. 6 Fuure Works The ools used in he paper, included MONOPOLY and ARTiS, are only for x86 machines. They can be used in mos embedded sysems such as ARM and PowerPC plaforms. In he fuure, we will plan o por MONOPOLY o he seleced embedded sysem, Xilinx ML310 Developmen Plaform, which includes wo PowerPC 405 processors ha conneced wih IBM CoreConnec on-chip bus. In Linux 2.6, here are 250 imes imer inerrup in one second by defaul. Tha means i coss quie a few resources for scheduling and deciding o conex swich or no. Accordingly, we also plan o design a hardware scheduler o reduce he workload of sofware scheduler beween wo processors on FPGA, o accelerae he performance of he presened user adjusable dynamic scheduler in his paper. 7 Acknowledgemen This work is suppored in par by he Naional Science Council of Republic of China, Taiwan under Gran NSC E Reference: [1] J. Aas, Undersanding he Linux CPU Scheduler, 2005 Silicon Graphics, Inc, Feb [2] R. Love, Linux Kernel Developmen, SAMS, Developer Library Series, [3] E. Piel, P. Marque, J. Soula, J.L. Dekeyser, Asymmeric Real-Time Scheduler on Muli-Processor Archiecure, 20h Inernaional Parallel and Disribued Processing Symposium, 2006 (IPDPS 2006), pp , Apr [4] G. E. Allen and B. L. Evans. Real-ime sonar beamforming on worksaions using process neworks and POSIX hreads, IEEE Transacions on Signal Processing, pp , Mar [5] K. Morgan, Preempible Linux: A realiy check, Whie paper, MonaVisa Sofware, Inc., [6] J. D. Valois. Implemening lock-free queues. In Proceedings of he Sevenh Inernaional Conference on Parallel and Disribued Compuing Sysems, Las Vegas, NV, Oc