API para Monitoramento de Desempenho em Sistemas Multicore Embarcados(API for Performance Monitoring in Embedded Multicore Systems)

Giovani Gracioli e Antonio Augusto FrohlichLaboratorio de Integracao Software/Hardware

Universidade Federal de Santa CatarinaFlorianopolis, Brasil

{giovani,guto}@lisha.ufsc.br

Abstract—Hardware Performance Counters (HPCs) are spe-cial registers available in the most modern processors that canbe used to monitor shared hardware resources in multicoreprocessors. Specifically for embedded real-time applicationsrunning on a multicore processor, such shared resources canaffect their performance and cause deadline misses. This paperpresents a hardware performance counter interface designedto embedded systems. The use of the interface is demonstratedthrough a benchmark that shares data between two threadsexecuting in different cores of a multicore processor. As aresult, the operating system can obtain an accurate view ofsoftware’s behavior.

Keywords-Hardware counters, operating systems, multicore

I. INTRODUCAO

Processadores multicore estao sendo cada dia mais us-ados no contexto de sistemas embarcados de tempo real(SETR) devido a evolucao e integracao de funcionalidadesem tais sistemas. Por exemplo, em um automovel moderno,novas funcoes de seguranca como “parada automatica deemergencia” e “auxılio de visao noturna” devem ler dadosdos sensores, processar o vıdeo e exibir avisos preventivosquando um obstaculo e detectado na via em tempo real [1].Alem disso, a adicao de novas funcionalidades ao sistemacusta em termos de consumo de energia, dissipacao decalor e espaco (e.g., cabeamento) [2]. Assim, processadoresmulticore tornam-se uma alternativa para diminuir essescustos e integrar as diversas funcoes em uma unica unidadede processamento, ao contrario de se ter diversas unidadesde controle eletronicas espalhadas no veıculo.

Entretanto, e difıcil garantir que os deadlines de temposerao atendidos em uma arquitetura multicore, principal-mente devido ao compartilhamento de diferentes recur-sos fısicos, tais como a memoria cache, barramentos eperifericos [3]. Neste contexto, e importante que o sistemaoperacional de tempo real (SOTR) seja capaz de correta-mente monitorar quando a disputa por recursos compar-tilhados influencia o tempo de execucao das threads e,consequentemente, a perda de deadlines.

Um exemplo de compartilhamento de recursos em umprocessador multicore, que pode ocasionar a perda de dead-lines, e o compartilhamento de dados. Tradicionalmente,

cada core possui uma cache privada e uma cache de nıvel2 ou 3, que e compartilhada por todos os cores. Quandoexiste dado compartilhado, cada copia do dado e armazenadana cache privada dos cores e um protocolo de coerenciade cache garante a consistencia entre as copias, atraves desnooping no barramento. Quando um core escreve no dadocompartilhado, o protocolo de coerencia invalida todas ascopias, causando um atraso implıcito na escrita do dado.A leitura e escrita frequentes a um dado compartilhadocausa a serializacao de acessos a mesma linha da cache e asaturacao do barramento entre os cores, aumentando o tempode execucao da aplicacao [4].

Neste contexto, contadores de desempenho de hardware(HPCs - Hardware Performance Counters) sao uma boaalternativa para monitorar quando eventos de hardware quepodem causar disputa por recursos compartilhados aconte-cem. HPCs sao registradores especiais presentes na maioriados microprocessadores modernos atraves de uma unidadede monitoramento de desempenho (PMU - PerformanceMonitoring Unit). HPCs oferecem suporte para contar ouamostrar diversos eventos microarquiteturais. Em um pro-cessador multicore, por exemplo, e possıvel contar o numerode snoops no barramento, numero de ciclos em que dadossao enviados pelo barramento, entre outros. Com base nasmedicoes dos HPCs, o SOTR pode tomar uma decisao, comoescalonar ou nao uma thread em um determinado instanteou move-la para um outro core.

Este artigo apresenta uma interface para uma famılia dePMUs especificamente projetada para sistemas embarcados.A interface utiliza o conceito de mediadores de hardware [5]para criar uma camada de comunicacao entre o software e ohardware de maneira simples, eficiente, com baixo consumode memoria e portavel. Para demonstrar o uso da interfaceproposta, uma aplicacao que gera excessivas invalidacoesna mesma linha de cache e utilizada e seu codigo fonte erelacionado com os eventos mensurados pelos HPCs.

O restante deste artigo esta organizado da seguinte forma.A Secao II apresenta o conceito de mediadores de hardware.A secao III apresenta a interface para uma famılia de PMUs.A correlacao entre o codigo fonte da aplicacao e os eventosde hardware e apresentada na Secao IV. A Secao V discute

2011 Brazilian Symposium on Computing System Engineering

978-0-7695-4641-4/11 $26.00 © 2011 IEEE

DOI 10.1109/SBESC.2011.27

197

2011 Brazilian Symposium on Computing System Engineering

978-0-7695-4641-4/11 $26.00 © 2011 IEEE

DOI 10.1109/SBESC.2011.27

197

2011 Brazilian Symposium on Computing System Engineering

978-0-7695-4641-4/11 $26.00 © 2011 IEEE

DOI 10.1109/SBESC.2011.27

197

2011 Brazilian Symposium on Computing System Engineering

978-0-7695-4641-4/11 $26.00 © 2011 IEEE

DOI 10.1109/SBESC.2011.27

194

os trabalhos relacionados e a Secao VI conclui o artigo.

II. MEDIADORES DE HARDWARE

A metodologia de Projeto de Sistemas Embarcados Di-rigido pela Aplicacao (ADESD) [6], define o conceito demediadores de hardware [5]. Mediadores de hardware saofuncionalmente equivalentes aos drivers de dispositivos emSOs baseados em UNIX, mas nao apresentam uma camadade abstracao de hardware (HAL - Hardware AbstractionLayer) tradicional. Mediadores provem uma interface entreos componentes do SO e o hardware atraves de tecnicasde metaprogramacao estatica e inlining de metodos quediluem o codigo do mediador nos componentes em tempode execucao. Consequentemente, o codigo gerado nao possuichamadas a metodos, nem camadas ou mensagens, atingindouma maior portabilidade e reuso em comparacao com asHALs tradicionais [7].

A Figura 1 apresenta um exemplo de mediador de hard-ware para uma famılia de CPUs. Este mediador trata amaioria das dependencias do gerenciamento de processos.A classe CPU::CONTEXT e definida por cada arquite-tura e representa os dados necessarios para um fluxo deexecucao, ou seja, o contexto de execucao. O metodoCPU::switch context e responsavel pela troca de contexto,recebendo o contexto antigo e o novo. Os mediadores deCPU implementam tambem uma serie de funcionalidadescomo habilitacao e desabilitacao de interrupcoes e operacaode bloqueio (e.g., test and set lock). Cada arquitetura aindadefine um conjunto de registradores e enderecos especıficos,porem a mesma interface permanece. Assim, e possıvelmanter as mesmas operacoes para os componentes indepen-dentes de arquitetura que usam a CPU tais como thread,sincronizadores e temporizadores.

Figure 1. Mediador de hardware CPU.

III. INTERFACE PARA PMU

Atraves do uso do conceito de mediadores de hardwareapresentado, uma interface para a famılia de PMUs da Intelfoi projetada. A Figura 2 mostra o diagrama de classes UMLda interface proposta. Os processadores Intel, dependendo damicroarquitetura (e.g., Nehalem, Core, Atom, etc), possuemdiferentes versoes da PMU. Cada versao prove diferentesfuncionalidades e um numero variavel de contadores de

hardware. Por exemplo, a PMU versao 2 possui dois con-tadores que podem ser configurados com eventos gerais etres contadores fixos que contam eventos especıficos. Jaa versao 3 estende a versao 2 e tem suporte para multi-threading (SMT) e ate 8 contadores [8]. Existem tambemeventos arquiteturais pre-definidos que sao compartilhadospelas 3 versoes, como numero de misses no ultimo nıvel decache e numero de instrucoes executadas.

Figure 2. Diagrama de classes UML da interface de mediadores dehardware da famılia de PMUs da Intel.

A tarefa de configurar um evento envolve a programacaode um registrador de selecao (IA32 PERFEVTSELx) cor-respondente a um contador fısico (IA32 PMCx). Existemdiversas mascaras associadas a cada evento e mascaras decontrole que devem ser escritas no registrador de evento paraque o contador comece a contar o evento selecionado. Porexemplo, para configurar o registrador PMC0 para contar onumero de respostas snoop de transacoes do barramento,o PERFEVTSEL0 deve ser escrito com o mascara doevento EXT SNOOP (0x77) e duas mascaras que definema condicao de quando o evento deve ser contado.

A famılia de mediadores de hardware projetada re-flete a organizacao das PMUs descritas. Uma classe baseIA32 PMU implementa a PMU versao 1 e servicos comunsas versoes 2 e 3, incluindo os eventos arquiteturais pre-definidos. Essa classe ainda declara os registradores mapea-dos em memoria e os contadores de hardware (PMCs). Aclasse IA32 PMU Version2 e IA32 PMU Version3 esten-dem a classe base e implementam os servicos especıficos

198198198195

somente disponıveis aquela versao. Finalmente, os eventosde hardware disponıveis para cada microarquitetura saolistados por suas respectivas classes. Por exemplo, a classeIntel Core Micro PMU lista todas mascaras de eventosrelacionadas com a microarquitetura Intel Core.

A interface de mediadores de hardware poderia ser us-ada por um componente independente de plataforma. Essecomponente seria o responsavel por agregar inteligencia aosmediadores. Por exemplo, taxas como paralelizacao, dadoscompartilhados modificados e utilizacao do barramento com-binam dois ou mais eventos de hardware com o intuito deprover uma melhor compreensao do comportamento e de-sempenho das aplicacoes [9]. Alem disso, este componentepoderia multiplexar os contadores para superar a limitacaodo numero de contadores fısicos. Tecnicas de multiplexacaodividem o uso dos contadores no tempo, dando a visaode que existem mais contadores em hardware do que oprocessador possui. No entanto, o uso de multiplexacao podediminuir a precisao [10].

Para demonstrar o desempenho dos mediadores, o PMC0foi usado para contar o evento EXT SNOOP. O metodopara configurar o contador ocupou 32 bytes de codigo e 11instrucoes. Ja o metodo para a leitura do contador ocupou100 bytes e 40 instrucoes. Outras APIS projetadas parasistemas computacionais de proposito geral, tal como aPAPI [10], necessitam a inicializacao e criacao de listas ouconjunto de eventos que afetam o desempenho. Alem disso,essas APIs disponibilizam diversas funcionalidades, comogerenciamento de objetos ativos e tratamento de erros, quepodem nao ser de interesse de uma aplicacao embarcada e detempo real. Assim, uma interface especificamente projetadapara suprir as necessidades de uma aplicacao pode obterum melhor desempenho. Nao e o objetivo deste artigo, noentanto, comparar os mediadores propostos com as APIsde proposito geral pois elas sao de domınios diferentes.E importante salientar tambem que o mesmo conceito deinterface para PMUs pode ser aplicado em outras famıliasde processadores, como PowerPC e ARM.

IV. EXEMPLO DE USO

Com o intuito de demonstrar a utilidade da interfaceproposta em um processador multicore, um benchmark com-posto por duas versoes de uma mesma aplicacao e umaaplicacao de melhor-caso para efeitos comparativos foramdesenvolvidos (veja Figura 3):

• Sequencial: nesta versao, duas funcoes executam emordem sequencial. Nao existe qualquer tipo de compar-tilhamento de dados (Figura 3(a)).

• Paralela: duas threads executam ao mesmo tempo ecompartilham dados (Figura 3(b)). O objetivo e avaliaro desempenho da versao anterior quando implementadaem um processador multicore. As funcoes 1 e 2 deambas versoes tem as mesmas operacoes e acessosa memoria (veja Figura 4). Esta versao deveria ser

executada duas vezes mais rapida que a versao anterior.Nao foram utilizados nenhum tipo de sincronizadoresentre as threads pois o objetivo e demonstrar, atravesdos HPCs, o quanto a disputa por dados compartilhadosafeta o desempenho da aplicacao.

• Melhor-caso: duas threads executam em paralelo masnao ha compartilhamento de dados (Figura 3(c)). Oobjetivo desta aplicacao e ter um cenario onde haparalelismo mas nao ha compartilhamento de dados.

Func 2

end

Initia.

Func 1

(a)

Func 1Shared

data

end

Initia.

Func 2

(b)

Func 1

end

Initia.

Func 2

(c)

Figure 3. Aplicacoes do benchmark: (a) sequencial (b) paralela (c) melhor-caso.

1 register unsigned int sum0;2 register unsigned int sum1;3 for(unsigned int i = 0; i <= REP; i++) {4 for(unsigned int j = 0; j < ROWS; j++) {5 sum0 = 0;6 sum1 = 0;7 for(unsigned int k = 0; k < COLS; k++) {8 sum0 += array0[j][k];9 sum1 += array1[j][k];

10 }11 for(unsigned int k = 0; k < COLS; k++) {12 array0[j][0] = sum0;13 array1[j][0] = sum1;14 }15 }16 }

Figure 4. Parte do codigo fonte das aplicacoes sequencial e paralela.

A interface de mediadores proposta e o benchmark foramimplementados no EPOS [6]. As 3 aplicacoes possuemdois arrays bi-dimensionais com tamanho variavel (ROWSx COLS) e um laco de 10000 repeticoes. O escalonadorutilizado nos experimentos foi o CPU Affinity, no qual cadathread possui uma afinidade com um core. Os testes foramexecutados no processador Intel Core 2 Q9550 (Tabela I).

Intel Core 2 Q9550Frequencia 2.83 Ghz

Conjunto de instrucoes 64 bitsNumero de cores 4 (2 dual-core)

Velocidade do barramento Front-side bus 1.3 GhzCache nıvel 1 privada (L1) 64 KB 8-way set associative

Tamanho da cache L2 12 MB (2x 6 MB) 24-way set associativeTamanho da linha de cache 64 bytes

Arquitetura de memoria UMAProtocolo de coerencia MESI

Versao da PMU 2Microarquitetura Intel Core Microarchitecture

Table ICONFIGURACAO DO PROCESSADOR INTEL CORE 2 Q9550.

199199199196

Primeiramente, a media de 10 execucoes de cadaaplicacao foi medida. A Figura 5 apresenta os valoresobtidos atraves do componente Chronometer em escalalogarıtmica para cada versao. As dimensoes dos dois arrays(ROWS x COLS) foram configuradas em 64x64 (32 KB),128x128 (128 KB), 256x256 (512 KB), 512x512 (2 MB),1024x1024 (8 MB), 1536x1024 (12 MB), e 1536x1536(18 MB) que excede o tamanho da cache L2 (12 MB). Odesvio padrao apresentou uma variacao entre 0,01% e 1%do total do tempo de execucao. O tempo de execucao daversao paralela e sempre superior ao da versao sequencial,ate 1,55 vez mais lenta. Devido ao compartilhamento dosdados e invalidacoes da mesma linha de cache realizadaspelo protocolo de coerencia, o tempo de execucao da versaoparalela e afetado. A versao de melhor-caso foi cerca de 2vezes mais rapida que a sequencial. As linhas 9, 10, 13 e14 da Figura 4 sao as responsaveis por gerar as transacoesno barramento que aumentam o tempo de execucao.

Figure 5. Tempo de execucao do benchmark para cada tamanho dos arrays.

Com isso e possıvel constatar que o tempo de execucaodas aplicacoes pode ser afetado pela arquitetura dos pro-cessadores multicore atuais e, em caso de aplicacoes comrestricoes de tempo, deadlines podem ser perdidos. Assim, eextremamente desejavel que o SO seja capaz de monitorar edetectar em tempo real quando atividades que geram disputapor recursos compartilhados acontecam, a fim de tomardecisoes para que o desempenho das aplicacoes nao seja taodegradado. Portanto, a famılia de mediadores de hardwareproposta neste artigo e adequada para este fim.

Neste sentido, o proximo experimento realizado exem-plifica o uso da interface para medir o efeito de excessivasinvalidacoes da mesma linha de cache no hardware. O eventomedido foi o CMP SNOOP. Esse evento conta o numerode vezes que dados presentes na cache L1 de um core saorequisitados (snooped) por outro. Um snoop e realizadoatraves de uma porta de escrita na cache de dados L1.Consequentemente, frequentes snoops podem conflitar comescritas a cache de dados L1 e assim aumentar a latenciae impactar o desempenho [8]. A Figura 6 mostra partedo codigo fonte das aplicacoes utilizando o componentede monitoramento de desempenho (Perf Mon) que faz uso

do mediador de hardware implementado. As chamadas aosmetodos de configuracao e leitura do evento sao diluıdasem tempo de compilacao no codigo das aplicacoes, assimnenhuma chamada de metodo e gerada na imagem final.

1 ...2 int func0(void)3 {4 Perf_Mon perf0;5 perf0.l1_data_cache_snooped();6 register unsigned int sum0;7 do_work();8 cout << "\nSnoops func0 = " << perf0.get_l1_data_cache_snooped() << "\n";9 }

10 ...

Figure 6. Exemplo de como a API foi utilizada nos experimentos nasaplicacoes paralela e melhor-caso.

A Figura 7 mostra o numero de eventos mensurados paracada versao do benchmark e para cada tamanho dos arrays.O evento foi configurado para contar os snoops que geraminvalidacoes da mesma linha de cache. Uma invalidacao emuma linha de cache acontece quando o core nao possuiaquela linha ou quando a linha esta disponıvel somente paraleitura e o outro core deseja escrever nessa linha. As linhas13 e 14 do codigo fonte da Figura 4 sao responsaveis pelasinvalidacoes mensuradas por este evento.

Figure 7. Numero de snoops de uma linha de cache. O eventoCMP SNOOP foi configurado para contar os snoops de invalidacao detodos cores.

A versao paralela apresentou de 2 a 3 ordens de magni-tude mais snoops que as versoes sequencial e melhor-caso.Quando o tamanho dos dados e maior que a cache L2 (de12 MB a 18 MB), a versao paralela apresentou uma pequenaqueda no numero de snoops devido ao fato de que existemmais dados sendo substituıdos na cache (e.g., conflitos pelamesma linha de cache) e assim a probabilidade de um dadorequisitado nao estar na cache e menor. O desvio padraodo melhor-caso variou de 10% para 32 KB e 128 KB a0,05% para 18 MB. O desvio padrao maximo para as versoessequencial e paralela foi 4,82% para tamanho de 2 MBe 3,49% para 62 KB respectivamente. O numero total desnoops representa de 0,04% a 1,67% do total de escritasrealizadas pelo codigo em um core para a versao paralela ecerca de 0,0005% para as versoes sequencial e melhor-caso.

200200200197

Os snoops mensurados nas versoes sequencial e melhor-caso sao resultado das variaveis de controle (spinlocks)necessarias em um kernel multicore.. As linhas 13 e 14da Figura 4 sao responsaveis pelas escritas que geram oevento medido. As leituras nao sao consideradas pois elasnao geram transacoes de invalidacoes no barramento. Eimportante salientar que nem toda escrita ou leitura de umdado vai gerar um snoop no barramento. Dependendo doestado da linha da cache em um core (dado pelo protocolo decoerencia), uma acao e tomada pelo controlador de memoria.Por exemplo, considerando o protocolo de coerencia MESI,se a linha de cache em um core esta no estado E (exclusivo)e uma requisicao para leitura e vista no barramento, estecore deve mudar a linha para o estado S (compartilhado).Por outro lado, se um core escreve em uma linha de cacheno estado E ou M, nenhuma transacao no barramento egerada pois esta linha so esta presente na cache daquelecore. Invalidacoes da linha de cache acontecem apenas emescritas nas linhas de cache compartilhadas (estado S) ouinvalidas (estado I).

Os valores medidos na Figura 7 foram entao normalizadosem um perıodo de 10 ms dado pela Equacao 1:

N =AV Gs

AV Gex/10ms(1)

Onde AV Gs e a media de snoops e AV Gex e a mediado tempo de execucao. A Figura 8 mostra os valores nor-malizados para cada aplicacao e tamanho dos dados. Nota-se que praticamente nao existe variacao para as aplicacoessequencial e melhor-caso, cerca de 60 a 80 snoops em umperıodo de 10 ms. A versao paralela apresentou ate 100.000snoops em um perıodo. Esse grafico mostra a frequencia deinvalidacoes de uma linha da cache e como um evento dehardware pode ser utilizado pelo SO. Por exemplo, duranteum quantum de escalonamento, esse evento poderia sermonitorado e se o valor mensurado fosse maior que umvalor limite, o escalonador poderia tomar uma decisao deescalonar ou nao uma thread, move-la para o mesmo core deoutra ou ainda diminuir o grau de paralelismo para diminuira disputa pelos dados compartilhados.

Figure 8. Numero de snoops de uma linha de cache em um perıodo de10 ms.

A API proposta foi implementada em C++ em um SObaseado em componentes (EPOS). Sendo assim, a mesmainfra-estrutura de mediadores e componentes poderia serfacilmente utilizada por qualquer outro sistema operacionalbaseado em componentes e implementado em C++.

V. TRABALHOS RELACIONADOS

PAPI (Performance API) e a interface de codigo abertomais utilizada para monitoramento de desempenho atravesde HPCs [10]. PAPI consiste de uma camada independentede plataforma, uma interface de alto nıvel que prove co-mandos como leitura, inicializacao e parada dos contadorese uma interface de baixo nıvel que disponibiliza maisfuncionalidades aos desenvolvedores. Essa camada de baixonıvel poderia ser comparada aos mediadores de hardwarepropostos neste artigo. Entretanto, nao e objetivo nesse tra-balho, fazer uma comparacao entre as duas implementacoes.PAPI suporta uma grande variedade de arquiteturas, tendosido projetada para sistemas computacionais de propositogeral e esta em desenvolvimento por mais de 10 anos. Ainterface proposta, ao contrario, foi projetada para aplicacoesembarcadas que possuem seus requisitos conhecidos emtempo de projeto. Assim, e possıvel gerar somente ocodigo necessario para a aplicacao, economizando recursose deixando a comunicacao entre software e hardware maisrapida.

O LINUX abstrai o uso de HPCs atraves de um subsistemade contadores de desempenho. A ferramenta perf, disponıveljuntamente com o codigo fonte do SO, usa esse subsistema epermite que desenvolvedores obtenham e analisem o desem-penho de suas aplicacoes. Outras ferramentas como a IntelVTUNE [9] e AMD CODEANALYST [11] oferecem umainterface grafica “amigavel” para monitorar o desempenhode processadores e aplicacao atraves de HPCs. Entretanto,SETR geralmente nao apresentam uma interface entre odesenvolvedor/usuario e o sistema em si.

Existem trabalhos que utilizam HPCs juntamente como escalonador do SO para dinamicamente tomar decisoescomo mover threads de um core para outro. Bellosa eSteckermeier foram os primeiros autores a usar HPCs comesse proposito [12]. Weissman usa HPCs para monitorar onumero de cache misses em um quantum de escalonamentoe, juntamente com anotacoes do desenvolvedor no codigofonte, montar um grafo representando as dependencias doestado da cache entre as threads [13]. O objetivo e avaliaros efeitos do tamanho dos dados das threads na cache deum processador. Com base no modelo, sao propostas duaspolıticas de escalonamento.

Tam et al. usaram HPCs para monitorar os enderecos delinhas de cache que sao invalidados devido a coerencia decache. Uma estrutura de dados que contem os enderecoslidos e construıda para cada thread do sistema [14]. Usandoas informacoes desta estrutura, o escalonador monta umgrupo composto por um conjunto de threads e aloca este

201201201198

grupo a um core especıfico. West et al. propuseram umatecnica baseada em um modelo estatıstico para estimar aocupacao da cache por cada thread do sistema em tempode execucao [15]. No entanto, compartilhamento de dadosentre as threads tambem nao e considerado pelos autores.

Zhuravlev identifica os principais problemas que causamcontencao em processadores multicore: contencao pelo con-trolador de memoria, barramento de memoria, hardwareprefetching e espaco da cache [3]. Os autores ainda propoemdois algoritmos de escalonamento que usam a taxa de missda cache para distribuir as threads de forma equilibrada entreos cores. Calandrino e Anderson tambem utilizam o numerode misses da cache para estimar o tamanho dos dados decada thread [16]. Baseando-se nesse numero estimado, umescalonador de tempo real e consciente do tamanho da cache,escalona as threads nos cores de maneira que nao causemthrashing na cache compartilhada.

VI. CONSIDERACOES FINAIS

Este artigo apresentou o projeto de uma famılia demediadores de hardware para unidades de monitoramentode desempenho presentes nos processadores atuais, dentrodo contexto de sistemas embarcados. O codigo geradopelos mediadores e diluıdo em tempo de compilacao noscomponentes que os utilizam. Assim, e obtido um baixoconsumo de memoria e um bom desempenho, caracterısticasdesejaveis para um sistema embarcado. Com o intuitode demonstrar a utilizacao dos mediadores propostos, umbenchmark que compartilha dados entre duas threads foiimplementado e os mediadores propostos foram usadospara prover ao sistema operacional uma visao da relacaoentre o software em execucao e os eventos gerados nohardware por esse software. Como trabalhos futuros, serautilizado o suporte a HPCs juntamente com o escalonadorpara garantir o atendimento aos deadlines em aplicacoesembarcadas de tempo real. Um componente independente deplataforma responsavel por agregar funcionalidades a famıliade mediadores de PMU tambem sera alvo de implementacao.

AGRADECIMENTOS

Este trabalho foi financiado pela CAPES, projeto RH-TVD 006/2008.

REFERENCES

[1] S. Mohan, M. Caccamo, L. Sha, R. Pellizzoni, G. Arundale,R. Kegley, and D. de Niz, “Using multicore architectures incyber-physical systems,” in Workshop on Developing Depend-able and Secure Automotive Cyber-Physical Systems fromComponents, Michigan, USA, Mar 2011.

[2] C. Cullmann, C. Ferdinand, G. Gebhard, D. Grund, C. Maiza,J. Reineke, B. Triquet, S. Wegener, and R. Wilhelm, “Pre-dictability considerations in the design of multi-core embed-ded systems,” Ingenieurs de l’Automobile, vol. 807, pp. 36–42, September 2010.

[3] S. Zhuravlev, S. Blagodurov, and A. Fedorova, “Address-ing shared resource contention in multicore processors viascheduling,” in Proceedings of the 15th edition of ASPLOSon Architectural support for programming languages andoperating systems, ser. ASPLOS ’10, 2010, pp. 129–142.

[4] S. Boyd-Wickizer, A. T. Clements, Y. Mao, A. Pesterev, M. F.Kaashoek, R. Morris, and N. Zeldovich, “An Analysis ofLinux Scalability to Many Cores,” in OSDI 2010: Proceed-ings of the 9th USENIX conference on Operating SystemsDesign and Implementation, 2010.

[5] F. V. Polpeta and A. A. Frohlich, “Hardware mediators:a portability artifact for component-based systems,” in InProceedings of the International Conference on Embeddedand Ubiquitous Computing, ser. Lecture Notes in ComputerScience, vol. 3207. Aizu, Japan: Springer Berlin / Heidel-berg, 2004, pp. 45–53.

[6] A. A. Frohlich, Application-Oriented Operating Systems,ser. GMD Research Series. Sankt Augustin: GMD -Forschungszentrum Informationstechnik, Aug. 2001, no. 17.

[7] H. Marcondes, A. S. Hoeller, L. F. Wanner, and A. A.Frohlich, “Operating systems portability: 8 bits and beyond,”in ETFA ’06: IEEE Conference on Emerging Technologiesand Factory Automation, Sept. 2006, pp. 124 –130.

[8] Intel Corporation, Intel R© 64 and IA-32 Architectures SoftwareDeveloper’s Manual, January 2011, no. 253668-037US.

[9] R. K. Malladi, Using Intel R© VTuneTM Performance AnalyzerEvents/Ratios Optimizing Applications, no. Intel R© WhitePaper.

[10] J. Dongarra, K. London, S. Moore, P. Mucci, D. Terpstra,H. You, and M. Zhou, “Experiences and lessons learned witha portable interface to hardware performance counters,” inProceedings of the 17th International Symposium on Paralleland Distributed Processing, ser. IPDPS ’03. Washington,DC, USA: IEEE Computer Society, 2003, pp. 289.2–.

[11] P. J. Drongowski, An introduction to analysis and optimiza-tion with AMD CodeAnalyst Performance Analyzer, Septem-ber 2008.

[12] F. Bellosa and M. Steckermeier, “The performance im-plications of locality information usage in shared-memorymultiprocessors,” Journal of Parallel Distributed Computing,vol. 37, pp. 113–121, August 1996.

[13] B. Weissman, “Performance counters and state sharing anno-tations: a unified approach to thread locality,” SIG. Operat.Sys. Rev., vol. 32, pp. 127–138, October 1998.

[14] D. Tam, R. Azimi, and M. Stumm, “Thread clustering:sharing-aware scheduling on smp-cmp-smt multiprocessors,”SIG. Operat. Sys. Rev., vol. 41, pp. 47–58, March 2007.

[15] R. West, P. Zaroo, C. A. Waldspurger, and X. Zhang, “On-line cache modeling for commodity multicore processors,”SIGOPS Ope. Sys. Rev., vol. 44, pp. 19–29, December 2010.

[16] J. M. Calandrino and J. H. Anderson, “On the design andimplementation of a cache-aware multicore real-time sched-uler,” in Proc. of the 21st Euromicro Conference on Real-TimeSystems, Washington, DC, USA, 2009, pp. 194–204.

202202202199