BR112019015427B1 - Coleta de evento de hardware síncrono - Google Patents

Coleta de evento de hardware síncrono Download PDF

Info

Publication number
BR112019015427B1
BR112019015427B1 BR112019015427-2A BR112019015427A BR112019015427B1 BR 112019015427 B1 BR112019015427 B1 BR 112019015427B1 BR 112019015427 A BR112019015427 A BR 112019015427A BR 112019015427 B1 BR112019015427 B1 BR 112019015427B1
Authority
BR
Brazil
Prior art keywords
trace
hardware
collection system
event
data
Prior art date
Application number
BR112019015427-2A
Other languages
English (en)
Other versions
BR112019015427A2 (pt
Inventor
Thomas Norrie
Naveen Kumar
Original Assignee
Google Llc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Google Llc filed Critical Google Llc
Publication of BR112019015427A2 publication Critical patent/BR112019015427A2/pt
Publication of BR112019015427B1 publication Critical patent/BR112019015427B1/pt

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/30Monitoring
    • G06F11/3003Monitoring arrangements specially adapted to the computing system or computing system component being monitored
    • G06F11/302Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system component is a software system
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/30Monitoring
    • G06F11/3065Monitoring arrangements determined by the means or processing involved in reporting the monitored data
    • G06F11/3072Monitoring arrangements determined by the means or processing involved in reporting the monitored data where the reporting involves data filtering, e.g. pattern matching, time or event triggered, adaptive or policy-based reporting
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/30Monitoring
    • G06F11/34Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3466Performance evaluation by tracing or monitoring
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/30Monitoring
    • G06F11/34Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3466Performance evaluation by tracing or monitoring
    • G06F11/348Circuit details, i.e. tracer hardware
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/30Monitoring
    • G06F11/34Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3466Performance evaluation by tracing or monitoring
    • G06F11/3495Performance evaluation by tracing or monitoring for systems
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/36Preventing errors by testing or debugging software
    • G06F11/3604Software analysis for verifying properties of programs
    • G06F11/3612Software analysis for verifying properties of programs by runtime analysis
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/36Preventing errors by testing or debugging software
    • G06F11/362Software debugging
    • G06F11/3644Software debugging by instrumenting at runtime
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/54Interprogram communication
    • G06F9/542Event management; Broadcasting; Multicasting; Notifications
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/86Event-based monitoring
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/865Monitoring of software

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Quality & Reliability (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • Computing Systems (AREA)
  • Mathematical Physics (AREA)
  • Multimedia (AREA)
  • Computer Vision & Pattern Recognition (AREA)
  • Debugging And Monitoring (AREA)
  • Advance Control (AREA)
  • Testing And Monitoring For Control Systems (AREA)

Abstract

um método implementado por computador que inclui a monitoramento da execução de código de programa pelo primeiro e segundo componentes de processador. um sistema de computação detecta que uma condição de gatilho é satisfeita ao: i) identificar um operando em uma porção do código de programa; ou ii) determinar que a hora atual de um relógio de sistema de computação indica um valor de tempo predefinido. o operando e o valor de tempo predefinido são usados para iniciar eventos de rastreamento. quando a condição de gatilho é satisfeita, o sistema inicia eventos de rastreamento que geram dados de rastreamento, identificando os respectivos eventos de hardware que ocorrem no sistema de computação. o sistema usa os dados de rastreamento para gerar um conjunto correlacionado de dados de rastreamento. os dados de rastreamento correlacionados indicam uma sequência ordenada por tempo dos respectivos eventos de hardware. o sistema usa o conjunto correlacionado de dados de rastreamento para analisar o desempenho do código de programa de execução.

Description

Antecedentes
[001] Este relatório descritivo refere-se à análise da execução de código de programa.
[002] A análise eficaz do desempenho de software distribuído executado em componentes de hardware distribuídos pode ser uma tarefa complexa. Os componentes de hardware distribuído podem ser respectivos núcleos de processador de duas ou mais Unidades de Processamento Central (CPUs) (ou Unidades de Processamento Gráfico (GPUs)) que cooperam e interagem para executar porções de um programa de software ou código de programa maior.
[003] Do ponto de vista do hardware (por exemplo, nas CPUs ou GPUs), geralmente há dois tipos de informações ou recursos disponíveis para análise de desempenho: 1) contadores de desempenho de hardware e 2) rastreamentos de eventos de hardware.
Sumário
[004] Em geral, um aspecto inovador do assunto descrito neste relatório descritivo pode ser incorporado em um método implementado por computador executado por um ou mais processadores, o método incluindo, monitorar a execução do código de programa por um primeiro componente de processador, o primeiro componente de processador sendo configurado para executar pelo menos uma primeira porção do código de programa; e monitorar a execução do código de programa por um segundo componente de processador, o segundo componente de processador sendo configurado para executar pelo menos uma segunda porção do código de programa.
[005] O método inclui ainda, detectar, por um sistema de computação, que uma condição de gatilho é satisfeita com base em pelo menos um dentre: i) identificar uma ocorrência de um operando em pelo menos na primeira porção do código de programa ou na segunda porção do código de programa, o operando incluindo um primeiro valor de parâmetro usado para iniciar um ou mais eventos de rastreamento, ou ii) determinar que uma hora atual de pelo menos um relógio de sistema de computação indica um valor de tempo predefinido usado para iniciar um ou mais eventos de rastreamento.
[006] Responsivo à detectar que a condição de gatilho é satisfeita, o método inclui, iniciar, pelo sistema de computação, pelo menos um primeiro evento de rastreamento que gera dados de rastreamento, os dados de rastreamento identificando os respectivos eventos de hardware ocorrendo nas unidades de processador distribuídas que incluem pelo menos o primeiro componente de processador e o segundo componente de processador. Para cada um dos respectivos eventos de hardware, os dados de rastreamento compreendem pelo menos um carimbo de hora de evento de hardware. O método inclui ainda, utilizando, pelo sistema de computação, os dados de rastreamento para gerar um conjunto correlacionado de dados de rastreamento que indica pelo menos uma sequência ordenada por tempo dos respectivos eventos de hardware que são gerados quando a condição de gatilho é satisfeita.
[007] Estas e outras implementações podem incluir, opcionalmente, um ou mais dos seguintes recursos. Por exemplo, em algumas implementações, o primeiro evento de rastreamento é um evento de rastreamento sincronizado que gera dados de rastreamento identificando eventos de hardware que ocorrem nas unidades de processador distribuídas, os dados de rastreamento também identificando um identificador de rastreamento exclusivo para os respectivos eventos de hardware, e em que os eventos de hardware incluem uma pluralidade de eventos de hardware sincronizados, e dois eventos de hardware são sincronizados quando os eventos compartilham um carimbo de hora de evento de hardware global.
[008] Em algumas implementações, detectar que a condição de gatilho é satisfeita compreende: detectar, pelo sistema de computação, que um dentre: i) o primeiro valor de parâmetro do operando excede um primeiro valor de um registro, ou ii) o valor de tempo predefinido indicado pela hora atual excede um primeiro valor de limite de um registro; e responsivo a detectar que a condição de gatilho é satisfeita, iniciar, pelo sistema de computação, um segundo evento de rastreamento que gera dados de rastreamento, em que os dados de rastreamento identificam pelo menos um atributo compartilhado entre os respectivos eventos de hardware que ocorrem nas unidades de processador distribuídas.
[009] Em algumas implementações, o método inclui ainda: detectar, pelo sistema de computação, que um dentre: um segundo valor de parâmetro do operando excede um segundo valor de limite do registro, ou um segundo valor de tempo predefinido indicado pela hora atual excede um segundo valor de limite do registro; e responsivo a detectar, parar, pelo sistema de computação, o segundo evento de rastreamento quando o segundo valor de parâmetro do operando excede o segundo valor de limite ou quando o segundo valor de tempo predefinido excede o segundo valor de limite.
[0010] Em algumas implementações, o operando inclui ainda pelo menos um dentre: um parâmetro indicando uma etapa de sequência específico do código de programa; ou um parâmetro de controle global que indica um estado de desempenho específico das unidades de processador distribuídas; e o valor de tempo predefinido inclui pelo menos um dentre: um valor de tempo específico indicado por um relógio de tempo global das unidades de processador distribuídas; ou um valor de tempo específico de uma janela de tempo predefinida associada ao relógio de tempo global.
[0011] Em algumas implementações, o operando possui uma primeira estrutura de dados binários e o primeiro valor de parâmetro do primeiro operando corresponde a uma marca de rastreamento, o valor de tempo predefinido possui uma segunda estrutura de dados binários e a hora atual é indicada por um relógio de tempo global, e em que o relógio de tempo global é utilizado pelas unidades de processador distribuídas para gerar um ou mais carimbos de hora de evento de hardware.
[0012] Em algumas implementações, o método inclui ainda: inserir, por um compilador de sistema de computação, o operando da condição de gatilho pelo menos na primeira porção de código de programa executada pelo primeiro componente de processador; e inserir, pelo compilador de sistema de computação, pelo menos um valor de tempo predefinido da condição de gatilho pelo menos na segunda porção de código de programa executada pelo segundo componente de processador.
[0013] Em algumas implementações, iniciar pelo menos um do primeiro evento de rastreamento ou do segundo evento de rastreamento, inclui: gerar, pelo sistema de computação, um primeiro sinal de controle recebido por um primeiro registro de contagem do primeiro núcleo de processador, o primeiro sinal de controle fazendo com que dados associado a um primeiro evento de hardware sejam armazenados no primeiro registro de contagem; e gerar, pelo sistema de computação, um segundo sinal de controle recebido por um segundo registro de contagem do segundo núcleo de processador, o segundo sinal de controle fazendo com que os dados associados a um segundo evento de hardware sejam armazenados no segundo registro de contagem.
[0014] Em algumas implementações, os dados associados a um dos primeiros eventos de hardware ou ao segundo evento de hardware, compreendem pelo menos um dentre: um número de bytes escritos para um buffer de memória específico de um núcleo de processador específico das unidades de processador distribuídas; ou um número de instruções executadas por um núcleo de processador específico das unidades de processador distribuídas.
[0015] Em algumas implementações, o método inclui ainda: identificar, pelo sistema de computação, uma ocorrência de um segundo operando pelo menos em uma porção do código de programa executado pelo primeiro ou segundo componente de processador, o segundo operando incluindo um segundo valor de parâmetro; determinar, pelo sistema de computação, que uma condição de filtro é satisfeita com base no segundo valor de parâmetro do segundo operando um dentre: exceder um valor de limite específico de um registro ou estar abaixo de um valor de limite específico do registro; e responsivo a determinar que a condição de filtro é satisfeita, filtrar, pelo sistema de computação, um ou mais eventos de rastreamento, em que filtrar um ou mais eventos de rastreamento compreende impedir o armazenamento de dados de rastreamento associados a um ou mais eventos de hardware.
[0016] Outro aspecto inovador da matéria descrita neste relatório descritivo pode ser incorporado em um sistema de coleta de eventos de hardware, incluindo: um ou mais processadores incluindo um ou mais núcleos de processador; uma ou mais unidades de armazenamento legíveis por máquina para armazenar instruções que são executáveis por um ou mais processadores para executar operações que incluem: monitorar a execução do código de programa por um primeiro componente de processador, sendo o primeiro componente de processador configurado para executar pelo menos uma primeira porção do código de programa; e monitorar a execução do código de programa por um segundo componente de processador, sendo o segundo componente de processador configurado para executar pelo menos uma segunda porção do código de programa.
[0017] O método inclui ainda, detectar, por um sistema de computação, que uma condição de gatilho é satisfeita com base em pelo menos um dentre: i) identificar uma ocorrência de um operando pelo menos na primeira porção do código de programa ou a segunda porção do código de programa, o operando incluindo um primeiro valor de parâmetro usado para iniciar um ou mais eventos de rastreamento, ou ii) determinar que uma hora atual de pelo menos um relógio de sistema de computação indica um valor de tempo predefinido usado para iniciar um ou mais eventos de rastreamento.
[0018] Responsivo a detectar que a condição de gatilho é satisfeita, o método inclui, iniciar, pelo sistema de computação, pelo menos um primeiro evento de rastreamento que gera dados de rastreamento, os dados de rastreamento identificando os respectivos eventos de hardware ocorrendo nas unidades de processador distribuídas que incluem pelo menos o primeiro componente de processador e o segundo componente de processador. Para cada um dos respectivos eventos de hardware, os dados de rastreamento compreendem pelo menos um carimbo de hora de evento de hardware. O método inclui ainda, utilizar, pelo sistema de computação, os dados de rastreamento para gerar um conjunto correlacionado de dados de rastreamento que indica pelo menos uma sequência ordenada por tempo dos respectivos eventos de hardware que são gerados quando a condição de gatilho é satisfeita.
[0019] Em geral, um aspecto inovador da matéria descrita neste relatório descritivo pode ser incorporado em um método implementado por computador executado por um ou mais processadores, o método incluindo, monitorar a execução do código de programa por um componente de processador, sendo o componente de processador configurado para executar pelo menos uma primeira porção do código de programa.
[0020] O método inclui ainda, detectar, por um sistema de computação, que uma condição de gatilho é satisfeita com base em pelo menos um dentre: i) identificar uma ocorrência de um operando pelo menos na primeira porção do código de programa, o operando incluindo um primeiro valor de parâmetro usado para iniciar um ou mais eventos de rastreamento, ou ii) determinar que uma hora atual de pelo menos um relógio de sistema de computação indica um valor de tempo predefinido usado para iniciar o um ou mais eventos de rastreamento.
[0021] Responsivo a detectar que a condição de gatilho é satisfeita, o método inclui ainda, gerar, pelo sistema de computação, um sinal de controle recebido por um registro de contagem do componente de processador, o sinal de controle fazendo com que os dados de contagem associados a um evento de hardware sejam armazenados no registro de contagem; e gerar, pelo sistema de computação, uma estrutura de dados que indica um ou mais atributos de desempenho associados ao código de programa de execução, a estrutura de dados sendo gerada com base em um ou mais parâmetros de contagem dos dados de contagem armazenados.
[0022] Estas e outras implementações podem incluir, opcionalmente, um ou mais dos seguintes recursos. Por exemplo, em algumas implementações, o registro de contagem é um dos vários contadores de desempenho configurados para armazenar dados de contagem sobre o desempenho de um ou mais componentes de processador de sistema de computação, e em que pelo menos um contador de desempenho inclui um dentre: um contador de atividade, um contador de paralisação, contador estatístico ou um contador de amostragem.
[0023] Em algumas implementações, o um ou mais parâmetros de contagem indicam um dentre: i) um número de instruções recebidas por um componente de processador específico; ii) um número de instruções processadas pelo componente de processador específico; iii) um número de instruções executadas pelo componente de processador específico; ou iv) um número de leituras de memória, ou um número de gravações de memória, executadas pelo componente de processador específico.
[0024] Em algumas implementações, um atributo de desempenho associado ao código de programa de execução compreende um dentre: i) uma frequência de paralisação de um componente de processador específico que executa o código de programa; ii) uma indicação de que a utilização do componente de processador em específico está abaixo de um limite de utilização; ou iii) uma indicação de que uma fila de armazenamento de dados usada pelo componente de processador específico está em ou abaixo de um limite de ocupação de fila.
[0025] Outras implementações deste e de outros aspectos incluem sistemas, aparelhos e programas de computador correspondentes, configurados para executar as ações dos métodos, codificados em dispositivos de armazenamento de computador. Um sistema de um ou mais computadores pode ser configurado em virtude de software, firmware, hardware ou uma combinação deles instalados no sistema que, na operação, fazem com que o sistema execute as ações. Um ou mais programas de computador podem ser configurados em virtude de terem instruções que, quando executadas pelo aparelho de processamento de dados, fazem com que o aparelho execute as ações.
[0026] O assunto descrito neste relatório descritivo pode ser implementado em modalidades específicas de modo a realizar uma ou mais das seguintes vantagens. O sistema de rastreamento de hardware descrito aprimora a eficiência computacional usando gatilhos dinâmicos que são executados por meio de botões/recursos de hardware. Os gatilhos permitem a captura sincronizada de eventos baseados, em parte, em um contador de tempo global, operandos lógicos incorporados, e registros de hardware, em vez de puramente por meio de sequências codificadas que normalmente exigem recursos de sistema para monitorar e executar a captura de eventos.
[0027] Da mesma forma, o uso da memória de sistema é otimizado quando os gatilhos de hardware são ajustados para capturar eventos de curta duração e capturas globais sincronizadas que ocorrem simultaneamente, em vez de capturas de eventos ineficientes e não correlacionadas. Os controles para captura de eventos sincronizados de duração mais curta mitigam a sobrecarga de informações, permitindo que alguns recursos de memória permaneçam sem uso e disponíveis para outros processos de sistema.
[0028] Os detalhes de uma ou mais implementações da matéria descrita neste relatório descritivo são apresentados nos desenhos em anexo e na descrição abaixo. Outras possíveis características, aspectos e vantagens da matéria se tornarão aparentes a partir da descrição, dos desenhos e das reivindicações.
Breve Descrição dos Desenhos
[0029] A Figura 1 ilustra um diagrama de blocos de um sistema de computação de exemplo para rastreamento de hardware distribuído.
[0030] A Figura 2 ilustra um diagrama de blocos de cadeias de rastreamento e respectivos nós de um sistema de computação de exemplo para rastreamento de hardware distribuído.
[0031] A Figura 3 ilustra um diagrama de blocos de uma arquitetura de projeto de rastreamento de exemplo e uma estrutura de dados de exemplo.
[0032] A Figura 4 é um diagrama de blocos que indica a atividade de rastreamento para um evento de rastreamento de acesso direto à memória executado por um sistema de computação de exemplo para rastreamento de hardware distribuído.
[0033] A Figura 5 ilustra um exemplo de estrutura de dados para um contador de tempo global (GTC) e tabelas que indicam cenários de uso do GTC por um sistema de computação de exemplo para rastreamento de hardware distribuído.
[0034] A Figura 6 ilustra um diagrama de blocos de exemplos de contadores de tempo e recursos de hardware associados a componentes de um sistema de computação de exemplo para rastreamento de hardware distribuído.
[0035] A Figura 7 é um fluxograma de processo de um processo de exemplo para rastreamento de hardware distribuído.
[0036] Números de referência semelhantes e designações nos vários desenhos indicam elementos semelhantes.
Descrição Detalhada
[0037] A matéria descrita neste relatório descritivo geralmente se refere ao rastreamento de hardware distribuído. Em particular, um sistema de computação monitora a execução do código de programa executado por um primeiro núcleo de processador e a execução do código de programa executado por um segundo núcleo de processador. O sistema de computação armazena uma linha do tempo de eventos de hardware em um buffer de memória. Os eventos armazenados ocorrem em unidades de processador distribuídas que incluem pelo menos o primeiro e o segundo núcleo de processador.
[0038] A linha do tempo inclui, para cada um dos eventos de hardware, um carimbo de hora do evento e os metadados que caracterizam o evento de hardware. O sistema gera uma estrutura de dados, incluindo eventos de hardware da linha do tempo. O sistema armazena a estrutura de dados em um banco de memória de um dispositivo hospedeiro e usa a estrutura de dados para avaliar o desempenho do código de programa executado pelo primeiro ou segundo núcleo de processador. Neste contexto de rastreamento de eventos, este relatório descritivo descreve abordagens para o rastreamento de eventos de hardware em um sistema de computação distribuído, mostrado nas Figuras 1-4.
[0039] Este relatório descritivo descreve ainda abordagens para a coleta de eventos de hardware sincronizado com base em um ou mais mecanismos de gatilho, mostrados nas Figuras 5-7. Como será discutido em mais detalhes abaixo, aspectos dos sistemas de computação descritos neste relatório descritivo relacionam-se pelo menos à coleta coordenada/síncrona de dados de rastreamento e contagem de eventos. Em particular, pelo menos um aspecto inclui sistemas e métodos para coleta sincronizada de dados do contador de desempenho de hardware e dados de eventos de rastreamento dentro de um sistema independente, bem como distribuído. A coleta de eventos sincronizados aprimora a análise dos dados de desempenho e dos dados de depuração do código de programa distribuído. A análise aprimorada é obtida, em parte, por meio da correlação de eventos que ocorrem em resposta à execução de componentes/módulos de software conectados analisados pelo sistema 100.
[0040] A Figura 1 ilustra um diagrama de blocos de um sistema de computação de exemplo 100 para rastreamento de hardware distribuído. Conforme utilizado neste relatório descritivo, o rastreamento de sistema de hardware distribuído corresponde ao armazenamento de eventos que ocorrem dentro dos componentes e subcomponentes de um microchip de processador de exemplo. Além disso, tal como aqui utilizado, um sistema de hardware distribuído (ou sistema de rastreamento) corresponde a uma coleção de microchips de processador que cooperam para executar as respectivas porções de um código de software/programa configurado para execução distribuída entre a coleção de microchips de processador. Em algumas implementações, diferentes chips de processador de sistema 100 podem formar nós respectivos de sistema de hardware distribuído. Em implementações alternativas, um único chip de processador pode incluir um ou mais núcleos de processador e recursos de hardware que podem formar cada um dos respectivos nós do chip de processador.
[0041] Por exemplo, no contexto de uma unidade de processamento central (CPU), um chip de processador pode incluir pelo menos dois nós e cada nó pode ser um núcleo respectivo da CPU. Alternativamente, no contexto de uma unidade gráfica de processador (GPU), um chip de processador pode incluir pelo menos dois nós e cada nó pode ser um respectivo multiprocessador de streaming da GPU. O sistema de computação 100 pode incluir múltiplos componentes de processador. Em algumas implementações, os componentes de processador podem ser pelo menos um de um chip de processador, um núcleo de processador, um mecanismo de acesso à memória, ou pelo menos um componente de hardware de sistema de computação geral 100.
[0042] Em alguns casos, um componente de processador, tal como um núcleo de processador, pode ser um componente de função fixa configurado para executar pelo menos uma operação específica com base em pelo menos uma instrução emitida do código de programa de execução. Em outros casos, um componente de processador, como um mecanismo de acesso à memória (MAE), pode ser configurado para executar código de programa em um nível mais baixo de detalhe ou granularidade do que o código de programa executado por outros componentes de processador de sistema 100.
[0043] Por exemplo, o código de programa executado por um núcleo de processador pode gerar um descritor de MAE para ser gerado e transmitido/enviado para o MAE. Após o recebimento do descritor, o MAE pode executar uma operação de transferência de dados com base no descritor MAE. Em algumas implementações, as transferências de dados executadas pelo MAE podem incluir, por exemplo, a transferência de dados para e de certos componentes de sistema 100 através de certos caminhos de dados ou componentes de interface de sistema, ou a emissão de pedidos de dados para um barramento de configuração de exemplo do sistema 100.
[0044] Em algumas implementações, cada nó de tensor de um chip de processador de exemplo de sistema 100 pode ter pelo menos dois “front-ends” que podem ser blocos de hardware/recursos que processam instruções de programa. Como discutido em mais detalhe abaixo, um primeiro frontend pode corresponder ao primeiro núcleo de processador 104, enquanto um segundo front-end pode corresponder ao segundo núcleo de processador 106. Assim, os primeiro e segundo núcleos de processamento podem também ser aqui descritos como primeiro front-end 104 e segundo front-end 106.
[0045] Conforme utilizado neste relatório descritivo, uma cadeia de rastreamento pode ser um barramento de comunicação de dados físico específico, no qual as entradas de rastreamento podem ser colocadas para transmissão para um gerenciador de chips de exemplo dentro de sistema 100. As entradas de rastreamento recebidas podem ser palavras/estruturas de dados, incluindo vários bytes e vários valores binários ou dígitos. Assim, o descritor “palavra” indica um pedaço fixo de dados binários que podem ser manipulados como uma unidade por dispositivos de hardware de um núcleo de processador de exemplo.
[0046] Em algumas implementações, os chips de processador de sistema de rastreamento de hardware distribuído são processadores de múltiplos núcleos (ou seja, tendo múltiplos núcleos) que executam porções do código de programa nos respectivos núcleos do chip. Em algumas implementações, porções do código de programa podem corresponder a cálculos vetorizados para cargas de trabalho de inferência de uma rede neural multicamada de exemplo. Enquanto em implementações alternativas, porções de código de programa podem corresponder geralmente a módulos de software associados a linguagens de programação convencionais.
[0047] O sistema de computação 100 geralmente inclui um gerenciador de nó 102, um primeiro núcleo de processador (FPC) 104, um segundo núcleo de processador (SPC) 106, uma malha de nó (NF) 110, um roteador de dados 112 e um bloco de interface de hospedeiro (HIB) 114. Em algumas implementações, o sistema 100 pode incluir uma memória mux 108 que é configurada para executar a troca de sinal, multiplexação e demultiplexação. O sistema 100 inclui ainda um núcleo de tensor 116 que inclui o FPC 104 ali colocado. O núcleo de tensor 116 pode ser um exemplo de dispositivo computacional configurado para realizar cálculos vetorizados em matrizes de dados multidimensionais. O núcleo de tensor 116 pode incluir uma unidade de processamento de vetores (VPU) 118, que interage com uma unidade de matriz (MXU) 120, unidade de transposição (XU) 122 e unidade de redução e permutação (RPU) 124. Em algumas implementações, o sistema de computação 100 pode incluir uma ou mais unidades de execução de uma CPU ou GPU convencional, tais como unidades de carga/armazenamento, unidades de lógica aritmética (ULAs) e unidades de vetor.
[0048] Os componentes de sistema 100 incluem coletivamente um grande conjunto de contadores de desempenho de hardware, bem como hardware de suporte que facilita a conclusão da atividade de rastreamento nos componentes. Como descrito em mais detalhe abaixo, o código de programa executado pelos respectivos núcleos de processador de sistema 100 pode incluir gatilhos incorporados usados para ativar simultaneamente múltiplos contadores de desempenho durante a execução de código. Em geral, os gatilhos detectados fazem com que os dados de rastreamento sejam gerados para um ou mais eventos de rastreamento. Os dados de rastreamento podem corresponder a contagens de parâmetros incrementais que são armazenadas nos contadores e que podem ser analisadas para discernir as características de desempenho do código de programa. Os dados para os respectivos eventos de rastreamento podem ser armazenados em um meio de armazenamento de exemplo (por exemplo, um buffer de hardware) e podem incluir um carimbo de hora que é gerado em resposta à detecção do gatilho.
[0049] Além disso, os dados de rastreamento podem ser gerados para uma variedade de eventos que ocorrem nos componentes de hardware de sistema 100. Exemplos de eventos podem incluir operações de comunicação entre nós e através de nós, como operações de acesso direto à memória (DMA) e atualizações de sinalizador de sincronização (cada uma descrita em mais detalhes abaixo). Em algumas implementações, o sistema 100 pode incluir um contador de carimbo de hora globalmente síncrono geralmente referido como Contador de Tempo Global (“GTC”). Em outras implementações, o sistema 100 pode incluir outros tipos de relógios globais, como o Relógio de Relógio de Lamport.
[0050] O GTC pode ser usado para uma correlação precisa da execução do código de programa e do desempenho do código de software/programa que é executado em um ambiente de processamento distribuído. Adicionalmente, e relacionado em parte ao GTC, em algumas implementações de sistema 100 pode incluir um ou mais mecanismos de gatilho usados por programas de software distribuídos para iniciar e parar o rastreamento de dados em um sistema distribuído de uma maneira altamente coordenada.
[0051] Em algumas implementações, um sistema hospedeiro 126 compila código de programa que pode incluir operandos embutidos que acionam, após detecção, a captura e armazenamento de dados de rastreamento associados a eventos de hardware. Em algumas implementações, o sistema hospedeiro 126 fornece o código de programa compilado para um ou mais chips de processador de sistema 100. Em implementações alternativas, o código de programa pode ser compilado (com gatilhos incorporados) por um exemplo de compilador externo e carregado para um ou mais chips de processador de sistema 100. Em alguns casos, o compilador pode definir um ou mais bits de rastreamento (discutidos abaixo) associados a certos gatilhos que são incorporados em porções de instruções de software. O código de programa compilado pode ser um programa de software distribuído que é executado por um ou mais componentes de sistema 100.
[0052] O sistema hospedeiro 126 pode incluir um mecanismo de monitoramento 128 configurado para monitorar a execução do código de programa por um ou mais componentes de sistema 100. Em algumas implementações, o mecanismo de monitoramento 128 permite que o sistema hospedeiro 126 monitore a execução do código de programa executado pelo menos pelo FPC 104 e pelo SPC 106. Por exemplo, durante a execução de código, o sistema hospedeiro 126 pode monitorar, por meio do mecanismo de monitoramento 128, o desempenho do código de execução pelo menos ao receber linhas de tempo periódicas de eventos de hardware com base nos dados de rastreamento gerados. Embora um único bloco seja mostrado para o sistema hospedeiro 126, em algumas implementações, o sistema 126 pode incluir múltiplos hospedeiros (ou subsistemas de hospedeiro) que estão associados a múltiplos chips de processadores ou núcleos de chip de sistema 100.
[0053] Em outras implementações, comunicações entre nós que envolvem pelo menos três núcleos de processador podem fazer com que o sistema hospedeiro 126 monitore o tráfego de dados em um ou mais "saltos" intermediários conforme o tráfego de dados atravessa um caminho de comunicação entre o FPC 104 e um terceiro núcleo/nó do processador. Por exemplo, o FPC 104 e o terceiro núcleo de processador podem ser os únicos núcleos que executam o código de programa em determinado período de tempo. Assim, uma transferência de dados do FPC 104 para o terceiro núcleo de processador pode gerar dados de rastreamento para um salto intermediário no SPC 106 à medida que os dados são transferidos do FPC 104 para o terceiro núcleo de processador. Dito de outra maneira, durante o roteamento de dados no sistema 100, os dados de um primeiro chip de processador indo para um terceiro chip de processador podem precisar atravessar um segundo chip de processador e, assim, a execução da operação de roteamento de dados pode gerar entradas de rastreamento para atividade de roteamento no segundo chip.
[0054] Após a execução do código de programa compilado, os componentes de sistema 100 podem interagir para gerar linhas de tempo de eventos de hardware que ocorrem em um sistema de computador distribuído. Os eventos de hardware podem incluir eventos de comunicação entre nós e através de nós. Exemplos de nós de um sistema de hardware distribuído e suas comunicações associadas são descritos em mais detalhe abaixo com referência à Figura 2. Em algumas implementações, é gerada uma estrutura de dados que identifica uma coleção de eventos de hardware para pelo menos uma linha de tempo de evento de hardware. A linha do tempo permite a reconstrução de eventos que ocorrem no sistema distribuído. Em algumas implementações, a reconstrução de eventos pode incluir a ordenação correta de eventos com base na análise de registros de tempo gerados durante a ocorrência de um evento específico.
[0055] Em geral, um exemplo de sistema de rastreamento de hardware distribuído pode incluir os componentes acima descritos de sistema 100, bem como pelo menos um controlador de hospedeiro associado a um sistema hospedeiro 126. O desempenho ou depuração de dados obtidos de um sistema de rastreamento distribuído pode ser útil quando os dados do evento são correlacionados, por exemplo, em uma forma ordenada por tempo ou sequenciada. Em algumas implementações, a correlação de dados pode ocorrer quando vários eventos de hardware armazenados correspondentes aos módulos de software conectados são armazenados e, em seguida, sequenciados para análise estruturada pelo sistema hospedeiro 126. Para implementações incluindo múltiplos sistemas hospedeiros, a correlação dos dados obtidos através dos diferentes hospedeiros pode ser realizada, por exemplo, pelo controlador de hospedeiro.
[0056] Em algumas implementações, o FPC 104 e o SPC 106 são, cada um, núcleos distintos de um chip de processador de múltiplos núcleos; enquanto em outras implementações, o FPC e o SPC 104, 106 são respectivos núcleos de chips de processador de múltiplos núcleos distintos. Como indicado acima, o sistema 100 pode incluir unidades de processador distribuídas tendo pelo menos FPC 104 e SPC 106. Em algumas implementações, as unidades de processador distribuídas de sistema 100 podem incluir um ou mais componentes de hardware ou software configurados para executar pelo menos uma porção de um programa de software distribuído maior ou código de programa.
[0057] O roteador de dados 112 é uma interconexão inter-chip (ICI) que fornece caminhos de comunicação de dados entre os componentes de sistema 100. Em particular, o roteador 112 pode fornecer acoplamento ou conexões de comunicação entre o FPC 104 e o SPC 106, e entre os respectivos componentes associados aos núcleos 104, 106. A malha de nó 110 interage com o roteador de dados 112 para mover pacotes de dados dentro dos componentes de hardware distribuído e subcomponentes de sistema 100.
[0058] O gerenciador de nó 102 é um dispositivo de alto nível que gerencia funções de nó de baixo nível em chips de processador de múltiplos nós. Como discutido em mais detalhe abaixo, um ou mais nós de um chip de processador podem incluir gerenciadores de chips controlados pelo gerenciador de nó 102 para gerenciar e armazenar dados de eventos de hardware em registros de entrada locais. A memória mux 108 é um dispositivo de multiplexação que pode realizar operações de comutação, multiplexação e demultiplexação em sinais de dados fornecidos a um exemplo de memória externa de alta largura de banda (HBM) ou sinais de dados recebidos da HBM externa.
[0059] Em algumas implementações, uma entrada de rastreamento de exemplo (descrita abaixo) pode ser gerada, por mux 108, quando o mux 108 alterna entre o FPC 104 e o SPC 106. A memória mux 108 pode potencialmente impactar o desempenho de um núcleo de processador específico 104, 106 que não é capaz de acessar o mux 108. Assim, os dados de entrada de rastreamento gerados pelo mux 108 podem auxiliar na compreensão dos picos resultantes nas latências de certas atividades de sistema associadas aos respectivos núcleos 104, 106. Em algumas implementações, dados de eventos de hardware (por exemplo, pontos de rastreamento discutidos abaixo) originados dentro do mux 108 podem ser agrupados, em uma linha de tempo de evento de hardware de exemplo, juntamente com dados de evento para malha de nó 110. O agrupamento de eventos pode ocorrer quando determinada atividade de rastreamento faz com que dados de eventos para vários componentes de hardware sejam armazenados em um buffer de hardware de exemplo (por exemplo, registro de entrada de rastreamento 218, discutido abaixo).
[0060] No sistema 100, o hardware de análise de desempenho abrange FPC 104, SPC 106, mux 108, malha de nó 110, roteador de dados 112 e HIB 114. Cada um desses componentes ou unidades de hardware inclui contadores de desempenho de hardware, bem como funções e recursos de rastreamento de eventos de hardware. Em algumas implementações, o VPU 118, o MXU 120, o XU 122 e o RPU 124 não incluem seu próprio hardware de desempenho dedicado. Em vez disso, em tais implementações, o FPC 104 pode ser configurado para fornecer os contadores necessários para VPU 118, MXU 120, XU 122 e RPU 124.
[0061] O VPU 118 pode incluir uma arquitetura interna de projeto que suporta processamento de dados localizados de alta largura de banda e operações aritméticas associadas a elementos vetoriais de um exemplo de processador de vetor de matriz. O MXU 120 é uma unidade de multiplicação de matrizes configurada para executar, por exemplo, matriz de até 128x128 multiplicadas em conjuntos de dados vetoriais de multiplicandos.
[0062] A XU 122 é uma unidade de transposição configurada para executar, por exemplo, operações de transposição matricial de até 128x128 em dados vetoriais associados às operações de multiplicação de matrizes. A RPU 124 pode incluir uma unidade sigma e uma unidade de permuta. A unidade sigma executa reduções sequenciais nos dados vetoriais associados às operações de multiplicação de matrizes. As reduções podem incluir somas e vários tipos de operações de comparação. A unidade de permuta pode permutar ou replicar completamente todos os elementos de dados vetoriais associados às operações de multiplicação de matriz.
[0063] Em algumas implementações, o código de programa executado pelos componentes de sistema 100 pode ser representativo da aprendizagem de máquina, cálculos de inferência de rede neural e/ou uma ou mais funções de acesso direto à memória. Os componentes de sistema 100 podem ser configurados para executar um ou mais programas de software, incluindo instruções que fazem com que uma unidade(s) de processamento ou dispositivo(s) do sistema execute uma ou mais funções. O termo "componente" destina- se a incluir qualquer dispositivo de processamento de dados ou dispositivo de armazenamento, como registros de estado de controle ou qualquer outro dispositivo capaz de processar e armazenar dados.
[0064] O sistema 100 pode geralmente incluir várias unidades de processamento ou dispositivos que podem incluir um ou mais processadores (por exemplo, microprocessadores ou unidades de processamento central (CPUs)), unidades de processamento gráfico (GPUs), circuitos integrados específicos de aplicação (ASICs) ou uma combinação de diferentes processadores. Em modalidades alternativas, o sistema 100 pode incluir, cada um, outros recursos/dispositivos de computação (por exemplo, servidores baseados na nuvem) que fornecem opções de processamento adicionais para realizar computações relacionadas com funções de rastreamento de hardware descritas neste relatório descritivo.
[0065] As unidades de processamento ou dispositivos podem incluir ainda uma ou mais unidades de memória ou bancos de memória (por exemplo, registros/contadores). Em algumas implementações, as unidades de processamento executam instruções programadas armazenadas na memória para dispositivos de sistema 100 para executar uma ou mais funções descritas neste relatório descritivo. As unidades/bancos de memória podem incluir um ou mais meios de armazenamento legíveis por máquina não transitórios. O meio de armazenamento não transitório legível por máquina pode incluir memória de estado sólido, disco magnético e disco óptico, uma memória de acesso aleatório (RAM), uma memória somente leitura (ROM), uma memória de leitura programável apagável (por exemplo, EPROM, EEPROM ou Memória Flash), ou qualquer outro meio tangível capaz de armazenar informações.
[0066] A Figura 2 ilustra um diagrama de blocos de cadeias de rastreamento de exemplo e respectivos nós de exemplo 200, 201 utilizados para rastreamento de hardware distribuído executado pelo sistema 100. Em algumas implementações, os nós 200, 201 de sistema 100 podem ser nós diferentes dentro de um único processador de múltiplos núcleos. Em outras implementações, o nó 200 pode ser um primeiro nó em um primeiro chip de processador de múltiplos núcleos e o nó 201 pode ser um segundo nó em um segundo chip de processador de múltiplos núcleos.
[0067] Embora dois nós estejam representados na implementação da Figura 2, em implementações alternativas, o sistema 100 pode incluir vários nós. Para implementações que envolvem vários nós, as transferências de dados entre nós podem gerar dados de rastreamento em saltos intermediários ao longo de um caminho de dados de exemplo que atravessa vários nós. Por exemplo, saltos intermediários podem corresponder a transferências de dados que passam por nós distintos em um determinado caminho de transferência de dados. Em alguns casos, os dados de rastreamento associados aos eventos de rastreamento/hardware do ICI podem ser gerados para um ou mais saltos intermediários que ocorrem durante as transferências de dados de nós cruzados que passam por um ou mais nós.
[0068] Em algumas implementações, o nó 0 e o nó 1 são nós de tensor usados para cálculos vetorizados associados a porções de código de programa para cargas de trabalho de inferência. Como usado neste relatório descritivo, um tensor é um objeto geométrico multidimensional e exemplos de objetos geométricos multidimensionais incluem matrizes e matrizes de dados.
[0069] Como mostrado na implementação da Figura 2, o nó 200 inclui uma cadeia de rastreamento 203 que interage com pelo menos um subconjunto dos componentes de sistema 100. Da mesma forma, o nó 201 inclui uma cadeia de rastreamento 205 que interage com pelo menos um subconjunto dos componentes de sistema 100. Em algumas implementações, os nós 200, 201 são nós de exemplo do mesmo subconjunto de componentes, enquanto que em outras implementações, os nós 200, 201 são nós respectivos de subconjuntos de componentes distintos. O roteador de dados/ICI 112 inclui uma cadeia de rastreamento 207 que geralmente converge com as cadeias de rastreamento 203 e 205 para fornecer dados de rastreamento ao gerenciador de chips 216.
[0070] Na implementação da Figura 2, os nós 200, 201 podem cada um incluir subconjuntos de componentes respectivos tendo pelo menos FPC 104, SPC 106, malha de nó 110 e HIB 114. Cada componente dos nós 200, 201 inclui um ou mais muxes de rastreamento configurados para agrupar pontos de rastreamento (descritos abaixo) gerados por um componente específico do nó. O FPC 104 inclui um mux de rastreamento 204, a malha de nó 110 inclui os muxes de rastreamento 200a/b, o SPC 106 inclui os muxes de rastreamento 200a/b/c/d, o HIB 214 inclui o mux de rastreamento 214 e o ICI 212 inclui o mux de rastreamento 212. Em algumas implementações, um registro de controle de rastreamento para cada mux de rastreamento permite que pontos de rastreamento individuais sejam ativados e desativados. Em alguns casos, para um ou mais muxes de rastreamento, seus registros de controle de rastreamento correspondentes podem incluir bits de ativação individuais, além de controles de mux de rastreamento mais amplos.
[0071] Em geral, os registros de controle de rastreamento podem ser registros de estado de controle (CSR) convencionais que recebem e armazenam dados de instrução de rastreamento. Em relação aos controles de mux de rastreamento mais amplos, em algumas implementações, o rastreamento pode ser ativado e desativado com base em gravações de CSR executadas pelo sistema 100. Em algumas implementações, o rastreamento pode ser dinamicamente iniciado e interrompido, pelo sistema 100, com base no valor de um contador de tempo global (GTC), com base no valor de um registro de marca de rastreamento de exemplo no FPC 104 (ou núcleo 116), ou com base no valor de um registro de marca de rastreamento de exemplo no SPC 106.
[0072] Detalhes e descrições adicionais relacionadas com os sistemas e métodos para iniciar e parar a atividade rastreamento dinamicamente, bem como para a coleta de evento de hardware sincronizado são descritos em mais detalhe com referência às implementações das Figuras 5-7.
[0073] Em algumas implementações, para o núcleo 116, o FPC 104 pode usar um parâmetro de controle de rastreamento para definir uma janela de rastreamento associada à atividade de evento que ocorre no núcleo 116. O parâmetro de controle de rastreamento permite que a janela de rastreamento seja definida em termos de limites inferior e superior para o GTC, bem como limites inferior e superior para o registro de marca de rastreamento.
[0074] Em algumas implementações, o sistema 100 pode incluir funções que permitem a redução do número de entradas de rastreamento que são geradas, como recursos de filtragem de eventos de rastreamento. Por exemplo, o FPC 104 e o SPC 106 podem cada um incluir recursos de filtragem que limitam a taxa na qual cada núcleo define um bit de rastreamento em um descritor de rastreamento gerado de exemplo (descrito abaixo). O HIB 114 pode incluir recursos de filtragem semelhantes, como um limitador de taxa de DMA de exemplo, que limita os bits de rastreamento associados à captura de determinados eventos de rastreamento de DMA. Além disso, o HIB 114 pode incluir controles (por exemplo, através de um bit de habilitação) para limitar as entradas de rastreamento de DMA de fonte de filas.
[0075] Em algumas implementações, um descritor para uma operação DMA pode ter um bit de rastreamento que é definido por um compilador de exemplo de sistema hospedeiro 126. Quando o bit de rastreamento é definido, os recursos/botões de hardware que determinam e geram dados de rastreamento são usados para concluir um exemplo de evento de rastreamento. Em alguns casos, um bit de rastreamento final no DMA pode ser uma operação lógica "OR" entre um bit de rastreamento que é inserido estaticamente pelo compilador e um bit de rastreamento que é determinado dinamicamente por um componente de hardware específico. Portanto, em alguns casos, o bit de rastreamento gerado pelo compilador pode fornecer um mecanismo, além da filtragem, para reduzir uma quantidade total de dados de rastreamento gerados.
[0076] Por exemplo, um compilador de sistema hospedeiro 126 pode decidir apenas definir os bits de rastreamento para uma ou mais operações DMA remotas (por exemplo, um DMA em pelo menos dois nós) e limpar os bits de rastreamento para uma ou mais operações DMA locais (por exemplo, um DMA dentro de um determinado nó de tensor, como o nó 200). Dessa maneira, uma quantidade de dados de rastreamento que são gerados pode ser reduzida com base na atividade de rastreamento sendo limitada a operações de DMA de nó cruzado (ou seja, remotas), em vez de atividade de rastreamento que inclui operações de nó cruzado e DMA local.
[0077] Em algumas implementações, pelo menos um evento de rastreamento iniciado pelo sistema 100 pode ser associado a uma operação de acesso à memória que inclui várias operações intermediárias que ocorrem no sistema 100. Um descritor (por exemplo, um descritor de MAE) para a operação de acesso à memória pode incluir um bit de rastreamento que faz com que os dados associados às várias operações intermediárias sejam armazenados em um ou mais buffers de memória. Assim, o bit de rastreamento pode ser usado para "marcar" operações de memória intermediárias e gerar vários eventos de rastreamento em saltos intermediários da operação de DMA, à medida que os pacotes de dados atravessam o sistema 100.
[0078] Em algumas implementações, o ICI 112 pode incluir um conjunto de bits de ativação e um conjunto de filtros de pacotes que fornecem funcionalidade de controle para cada porta de entrada e saída de um componente específico do nó 200, 201. Estes permitem que os bits e os filtros de pacotes permitam que o ICI 112 ative e desative os pontos de rastreamento associados a componentes específicos dos nós 200, 201. Além de ativar e desativar os pontos de rastreamento, o ICI 112 pode ser configurado para filtrar os dados de rastreamento com base na origem de evento, no destino de evento e no tipo de pacote de eventos do rastreamento.
[0079] Em algumas implementações, além de usar o GTC ou marcadores de rastreamento, cada registro de controle de rastreamento para os núcleos de processador 104, 106 e HIB 114 também pode incluir um modo de rastreamento de "todos". Esse modo de rastreamento de "todos" pode permitir que o rastreamento em todo um chip de processador seja controlado pelo mux de rastreamento 204 ou pelo mux de rastreamento 206a. Enquanto no modo de rastreamento de todos, os muxes de rastreamentos 204 e 206a podem enviar um sinal de controle de rastreamento "na janela" que especifica se um mux de rastreamento específico, mux 204 ou mux 206a, está em uma janela de rastreamento.
[0080] O sinal de controle de rastreamento na janela pode ser difundido ou transmitido universalmente para todos os outros muxes de rastreamento, por exemplo, dentro de um chip de processador ou através de múltiplos chips de processador. A transmissão para outros muxes de rastreamento pode fazer com que todo rastreamento seja ativado quando o mux 204 ou o mux 206a estiver executando a atividade de rastreamento. Em algumas implementações, os muxes de rastreamento associados aos núcleos de processador 104, 106 e HIB 114 incluem, cada um, um registador de controle de janela de rastreamento que especifica quando e/ou como é gerado o sinal de controle de “rastreamento de todos”.
[0081] Em algumas implementações, a atividade de rastreamento em muxes de rastreamento 210a/b e mux de rastreamento 212 é geralmente ativada com base em se um bit de rastreamento é configurado em palavras de dados para operações DMA ou mensagens de controle que atravessam o ICI/roteador de dados 112. Operações de DMA ou mensagens de controle podem ser estruturas de dados binários de tamanho fixo que podem ter um bit de rastreamento dentro dos pacotes de dados binários definidos com base em determinadas circunstâncias ou condições de software.
[0082] Por exemplo, quando uma operação de DMA é iniciada no FPC 104 (ou SPC 106) com uma instrução DMA de tipo de rastreamento e o iniciador (núcleos de processador 104 ou 106) está em uma janela de rastreamento, o bit de rastreamento será definido nesse DMA específico. Em outro exemplo, para o FPC 104, mensagens de controle para gravações de dados em outro componente no sistema 100 terão o bit de rastreamento configurado se o FPC 104 estiver em uma janela de rastreamento e um ponto de rastreamento que faz com que os dados de rastreamento a serem armazenados sejam habilitados.
[0083] Em algumas implementações, as operações de DMA de comprimento zero fornecem um exemplo de uma implementação de DMA mais ampla no sistema 100. Por exemplo, algumas operações DMA podem produzir atividades não-DMA no sistema 100. A execução da atividade não-DMA também pode ser rastreada (por exemplo, gerar dados de rastreamento) como se a atividade não-DMA fosse uma operação de DMA (por exemplo, atividade de DMA incluindo operações de comprimento diferente de zero). Por exemplo, uma operação de DMA iniciada em um local de origem, mas sem nenhum dado (por exemplo, comprimento zero) a ser enviado ou transferido, poderia enviar uma mensagem de controle para o local de destino. A mensagem de controle indicará que não há dados a serem recebidos, ou trabalhados com, no destino, e a própria mensagem de controle seria rastreada pelo sistema 100 como uma operação de DMA de comprimento não zero seria rastreada.
[0084] Em alguns casos, para o SPC 106, operações de DMA de comprimento zero podem gerar uma mensagem de controle, e um bit de rastreamento associado à mensagem é definido somente se o DMA tivesse o bit de rastreamento definido, isto é, se a mensagem de controle não tivesse um comprimento zero. Em geral, as operações de DMA iniciadas a partir de sistema hospedeiro 126 terão o bit de rastreamento configurado se o HIB 114 estiver em uma janela de rastreamento.
[0085] Na implementação da Figura 2, a cadeia de rastreamento 203 recebe dados de entrada de rastreamento para o subconjunto de componentes que alinha com o nó 0, enquanto a cadeia de rastreamento 205 recebe dados de entrada de rastreamento para o subconjunto de componentes que alinha com o nó 1. Cada cadeia de rastreamento 203, 205, 207 são caminhos de comunicação de dados distintos utilizados pelos respectivos nós 200, 201 e ICI 112 para fornecer dados de entrada de rastreamento a um exemplo de registro de dados de entrada de rastreamento 218 de um gerenciador de chips 216. Assim, o ponto final das cadeias de rastreamento 203, 205, 207 é o gerenciador de chip 216, em que os eventos de rastreamento podem ser armazenados em unidades de memória de exemplo.
[0086] Em algumas implementações, pelo menos uma unidade de memória do gerenciador de chips 216 pode ter largura de 128 bits e pode ter uma profundidade de memória de pelo menos 20.000 entradas de rastreamento. Em implementações alternativas, pelo menos uma unidade de memória pode ter uma largura de bit maior ou menor e pode ter uma profundidade de memória capaz de armazenar mais ou menos entradas.
[0087] Em algumas implementações, o gerenciador de chips 216 pode incluir pelo menos um dispositivo de processamento executando instruções para gerenciar dados de entrada de rastreamento recebidos. Por exemplo, o gerenciador de chip 216 pode executar instruções para escanear/analisar dados de registro de tempo para os respectivos eventos de hardware de dados de rastreamento recebidos através das cadeias de rastreamento 203, 205, 207. Com base na análise, o gerenciador de chip 216 pode preencher o registro de entrada de rastreamento 218 para incluir dados que podem ser usados para identificar (ou gerar) uma sequência ordenada por tempo de eventos de rastreamento de hardware. Os eventos de rastreamento de hardware podem corresponder ao movimento de pacotes de dados que ocorrem ao nível do componente e do subcomponente, quando as unidades de processamento de sistema 100 executam um programa de software distribuído de exemplo.
[0088] Em algumas implementações, as unidades de hardware de sistema 100 podem gerar entradas de rastreamento (e carimbos de hora correspondentes) que preenchem um buffer de rastreamento de hardware de exemplo de uma maneira não ordenada pelo tempo (ou seja, fora de ordem). Por exemplo, o gerenciador de chips 216 pode fazer com que múltiplas entradas de rastreamento, tendo gerado carimbos de hora, sejam inseridas no registro de entrada 218. As entradas de rastreamento respectivas, das várias entradas de rastreamento inseridas, podem não ser ordenadas por tempo em relação umas às outras. Nesta implementação, entradas de rastreamento não ordenadas por tempo podem ser recebidas por um exemplo de buffer de hospedeiro de sistema hospedeiro 126. Após a recepção pelo buffer de hospedeiro, o sistema hospedeiro 126 pode executar instruções relacionadas ao software de análise/monitoramento de desempenho para escanear/analisar dados de carimbo de hora para as respectivas entradas de rastreamento. As instruções executadas podem ser usadas para classificar as entradas de rastreamento e para construir/gerar uma linha do tempo de eventos de rastreamento de hardware.
[0089] Em algumas implementações, as entradas de rastreamento podem ser removidas do registro de entrada 218 durante uma sessão de rastreamento por meio de uma operação de DMA do hospedeiro. Em algumas instâncias, o sistema hospedeiro 126 pode não entrar DMA fora do registro de entrada de rastreamento 218 tão rapidamente quanto elas são adicionadas ao registro. Em outras implementações, o registro de entrada 218 pode incluir uma profundidade de memória predefinida. Se o limite de profundidade de memória do registro de entrada 218 for atingido, entradas de rastreamento adicionais podem ser perdidas. Para controlar quais entradas de rastreamento são perdidas, o registro de entrada 218 pode operar no modo primeiro a entrar primeiro a sair (first-in-first-out, FIFO) ou, alternativamente, em um modo de gravação por substituição.
[0090] Em algumas implementações, o modo de gravação de substituição pode ser usado, pelo sistema 100, para suportar a análise de desempenho associada à depuração post-mortem. Por exemplo, o código de programa pode ser executado por um determinado período de tempo com a atividade de rastreamento ativada e o modo de gravação sobrescrito ativado. Em resposta a um evento de software post-mortem (por exemplo, uma falha de programa) no sistema 100, o software de monitoramento executado pelo sistema hospedeiro 126 pode analisar o conteúdo de dados de um buffer de rastreamento de hardware de exemplo para obter informações sobre eventos de hardware que ocorreram antes da falha do programa. Conforme usado neste relatório descritivo, a depuração post-mortem está relacionada à análise ou depuração do código de programa após o código ter falhado ou, em geral, falhou ao executar/operar conforme pretendido.
[0091] No modo FIFO, se o registro de entrada 218 estiver cheio, e se o sistema hospedeiro 126 remover as entradas de registro guardadas dentro de um determinado período de tempo, para conservar recursos de memória, novas entradas de rastreamento podem não ser guardadas em uma unidade de memória do gerenciador de chips 216. Enquanto no modo de gravação por substituição, se o registro de entrada 218 está cheio porque o sistema hospedeiro 126 remove as entradas de registro salvas em um determinado período de tempo, para conservar recursos de memória, novas entradas de rastreamento podem substituir a entrada de rastreamento mais antiga armazenada no registro de entrada 218. Em algumas implementações, as entradas de rastreamento são movidas para uma memória de sistema hospedeiro 126 em resposta a uma operação de DMA utilizando recursos de processamento do HIB 114.
[0092] Conforme utilizado neste relatório descritivo, um ponto de rastreamento é o gerador de uma entrada de rastreamento e dados associados à entrada de rastreamento recebida pelo gerenciador de chips 216 e armazenados no registro de entrada de rastreamento 218. Em algumas implementações, um microchip de processador de múltiplos nós de múltiplos núcleos pode incluir três cadeias de rastreamento dentro do chip, de forma que uma primeira cadeia de rastreamento receba entradas de rastreamento de um nó de chip 0, uma segunda cadeia de rastreamento receba entradas de rastreamento de um nó de chip 1 e uma terceira cadeia de rastreamento recebe entradas de rastreamento de um roteador ICI do chip.
[0093] Cada ponto de rastreamento possui um número de identificação de rastreamento exclusivo, dentro de sua cadeia de rastreamento, que é inserido no cabeçalho da entrada de rastreamento. Em algumas implementações, cada entrada de rastreamento identifica a cadeia de rastreamento de origem de um cabeçalho indicado por um ou mais bytes/bits da palavra de dados. Por exemplo, cada entrada de rastreamento pode incluir uma estrutura de dados com formatos de campos definidos (por exemplo, cabeçalho, carga útil, etc.) que transmitem informações sobre um determinado evento de rastreamento. Cada campo em uma entrada de rastreamento corresponde a dados úteis aplicáveis ao ponto de rastreamento que gerou a entrada de rastreamento.
[0094] Como indicado acima, cada entrada de rastreamento pode ser escrita ou armazenada dentro de uma unidade de memória do gerenciador de chip 216 associada ao registro de entrada de rastreamento 218. Em algumas implementações, os pontos de rastreamento podem ser ativados ou desativados individualmente e vários pontos de rastreamento podem gerar o mesmo tipo de entrada de rastreamento, embora com identificadores de ponto de rastreamento diferentes.
[0095] Em algumas implementações, cada tipo de entrada de rastreamento pode incluir um nome de rastreamento, uma descrição de rastreamento e um cabeçalho que identifica codificações para campos específicos e/ou uma coleção de campos dentro da entrada de rastreamento. O nome, descrição e cabeçalho coletivamente fornecem uma descrição do que a entrada de rastreamento representa. Do ponto de vista do gerenciador de chips 216, esta descrição também pode identificar a cadeia de rastreamento específica 203, 205, 207 na qual uma entrada de rastreamento específica entrou em um determinado chip de processador. Assim, os campos dentro de uma entrada de rastreamento representam partes de dados (por exemplo, em bytes/bits) relevantes para a descrição e podem ser um identificador de entrada de rastreamento usado para determinar qual ponto de rastreamento gerou uma entrada de rastreamento específica.
[0096] Em algumas implementações, os dados de entrada de rastreamento associados a um ou mais dos eventos de hardware armazenados podem corresponder, em parte, às comunicações de dados que ocorrem: a) entre pelo menos um nó 0 e um nó 1; b) entre pelo menos componentes dentro do nó 0; e c) entre pelo menos componentes dentro do nó 1. Por exemplo, eventos de hardware armazenados podem corresponder, em parte, a comunicações de dados que ocorrem entre pelo menos um dos seguintes: 1) FPC 104 do nó 0 e FPC 104 do nó 1; FPC 104 do nó 0 e SPC 106 do nó 0; 2) SPC 106 do nó 1 e SPC 106 do nó 1.
[0097] A Figura 3 ilustra um diagrama de blocos de um exemplo de arquitetura de desenho de mux de rastreamento 300 e um exemplo de estrutura de dados 320. O projeto de mux de rastreamento 300 geralmente inclui uma entrada de barramento de rastreamento 302, um arbitro de barramento 304, e um arbitro de ponto de rastreamento local 306, um barramento FIFO 308, pelo menos uma fila de eventos de rastreamento local 310, um evento de rastreamento compartilhado FIFO 312 e uma saída de barramento de rastreamento 314.
[0098] O projeto mux 300 corresponde a um mux de rastreamento de exemplo disposto dentro de um componente de sistema 100. O Mux projeto 300 pode incluir a seguinte funcionalidade. O barramento em 302 pode ser relacionado a dados de ponto de rastreamento local que são armazenados temporariamente no barramento FIFO 308 até que a lógica de arbitragem de tempo (por exemplo, o árbitro 304) possa fazer com que os dados de rastreamento sejam colocados em uma cadeia de rastreamento de exemplo. Um ou mais pontos de rastreamento para um componente podem inserir dados de eventos de rastreamento em pelo menos uma fila de eventos de rastreamento local 310. O árbitro 306 fornece arbitragem de primeiro nível e permite a seleção de eventos entre os eventos de rastreamento locais armazenados na fila 310. Os eventos selecionados são colocados no evento de rastreamento compartilhado FIFO 312, que também funciona como uma fila de armazenamento.
[0099] O árbitro 304 fornece uma arbitragem de segundo nível que recebe eventos de rastreamento locais da fila FIFO 312 e mescla os eventos de rastreamento locais em uma cadeia de rastreamento específico 203, 205, 207 por meio da saída de barramento de rastreamento 314. Em algumas implementações, as entradas de rastreamento podem ser inseridas em filas locais 310 mais rápidas do que podem ser mescladas ao FIFO compartilhado 312 ou, alternativamente, as entradas de rastreamento podem ser empurradas para o FIFO 312 compartilhado mais rápido do que podem ser mescladas na saída de barramento de rastreamento 314. Quando esses cenários ocorrem, as respectivas filas 310 e 312 ficarão cheias com dados de rastreamento.
[00100] Em algumas implementações, quando a fila 310 ou 312 fica cheia com dados de rastreamento, o sistema 100 pode ser configurado para que as entradas de rastreamento mais recentes sejam descartadas e não sejam armazenadas ou mescladas em uma fila específica. Em outras implementações, em vez de descartar entradas de rastreamento quando certas filas são preenchidas (por exemplo, filas 310, 312), o sistema 100 pode ser configurado para parar um pipeline de processamento de exemplo até que as filas que estão preenchidas tenham novamente espaço de fila disponível para receber entradas.
[00101] Por exemplo, um pipeline de processamento que usa filas 310, 312 pode ser parado até que um número suficiente ou mínimo de entradas de rastreamento seja mesclado no barramento de rastreamento 314. O número suficiente ou de limite pode corresponder a um número específico de entradas de rastreamento mescladas que resultam em espaço de fila disponível para uma ou mais entradas de rastreamento a serem recebidas pelas filas 310, 312. Implementações nas quais os pipelines de processamento são paralisados, até que o espaço de fila à jusante se torne disponível, podem fornecer dados de rastreamento de alta fidelidade com base em certas entradas de rastreamento sendo retidas em vez de descartadas.
[00102] Em algumas implementações, as filas de rastreamento locais são tão largas quanto requeridas pela entrada de rastreamento, de tal forma que cada entrada de rastreamento ocupa apenas um ponto na fila local 310. No entanto, a fila FIFO de rastreamento compartilhado 312 pode utilizar uma codificação de linha de entrada de rastreamento exclusiva, de modo que algumas entradas de rastreamento possam ocupar dois locais na fila compartilhada 312. Em algumas implementações, quando qualquer dado de um pacote de rastreamento é descartado, o pacote completo é descartado para que nenhum pacote parcial apareça no registro de entrada de rastreamento 218.
[00103] Em geral, um rastreamento é uma linha do tempo de atividades ou eventos de hardware associados a um componente específico de sistema 100. Ao contrário dos contadores de desempenho (descritos abaixo), que são dados agregados, os rastreamentos contêm dados de eventos detalhados que fornecem informações sobre a atividade de hardware que ocorre durante uma janela de rastreamento especificada. O sistema de hardware descrito permite amplo suporte para rastreamento de hardware distribuído, incluindo geração de entradas de rastreamento, armazenamento temporário de entradas de rastreamento em buffer gerenciado por hardware, ativação estática e dinâmica de um ou mais tipos de rastreamento, e fluxo de dados de entrada de rastreamento para o sistema hospedeiro 126.
[00104] Em algumas implementações, rastreamentos podem ser gerados para eventos de hardware executados por componentes de sistema 100, como gerar uma operação de DMA, executar uma operação de DMA, emitir/executar certas instruções ou atualizar sinalizadores de sincronização. Em alguns casos, a atividade de rastreamento pode ser usada para rastrear DMAs através de sistema ou para rastrear instruções executadas em um núcleo de processador específico.
[00105] O sistema 100 pode ser configurado para gerar pelo menos uma estrutura de dados 320 que identifica um ou mais eventos de hardware 322, 324 a partir de uma linha de tempo de eventos de hardware. Em algumas implementações, a estrutura de dados 320 organiza um ou mais eventos de hardware 322, 324 em uma sequência ordenada por tempo de eventos que estão associados com pelo menos FPC 104 e SPC 106. Em alguns casos, o sistema 100 pode armazenar a estrutura de dados 320 em um banco de memória de um dispositivo de controle hospedeiro de sistema hospedeiro 126. A estrutura de dados 320 pode ser utilizada para avaliar o desempenho do código de programa executado pelo menos pelos núcleos de processador 104 e 106.
[00106] Conforme mostrado por eventos de hardware 324, em algumas implementações, um número de identificação de rastreamento (ID) específico (por exemplo, ID de rastreamento '003) pode ser associado a vários eventos de hardware que ocorrem nas unidades de processador distribuídas. Os vários eventos de hardware podem corresponder a uma operação de acesso à memória específica (por exemplo, um DMA) e o número de ID do rastreamento específico é usado para correlacionar um ou mais eventos de hardware.
[00107] Por exemplo, conforme indicado pelo evento 324, um único ID de rastreamento para uma operação de DMA pode incluir várias etapas de tempo correspondentes a vários pontos diferentes no DMA. Em alguns casos, o ID de rastreamento '003 pode ter um evento "emitido", um evento "executado" e um evento "concluído" que são identificados como separados por algum tempo em relação um ao outro. Assim, a este respeito, o ID de rastreamento pode ainda ser utilizado para determinar um atributo de latência da operação de acesso à memória com base na correlação e com referência às etapas de tempo.
[00108] Em algumas implementações, a geração da estrutura de dados 320 pode incluir, por exemplo, o sistema 100 que compara carimbos de hora de evento dos respectivos eventos em um primeiro subconjunto de eventos de hardware com carimbos de hora de evento dos respectivos eventos em um segundo subconjunto de eventos de hardware. Gerar estrutura de dados 320 pode ainda incluir, sistema 100 fornecendo, para apresentação na estrutura de dados, um conjunto correlacionado de eventos de hardware baseado, em parte, na comparação entre o primeiro subconjunto de eventos e o segundo subconjunto de eventos.
[00109] Como mostrado na Figura 3, a estrutura de dados 320 pode identificar pelo menos um parâmetro que indica um atributo de latência de um evento de hardware específico 322, 324. O atributo de latência pode indicar pelo menos uma duração do evento de hardware específico. Em algumas implementações, a estrutura de dados 320 é gerada por instruções de software executadas por um dispositivo de controle de sistema hospedeiro 126. Em alguns casos, a estrutura 320 pode ser gerada em resposta ao dispositivo de controle que armazena dados de entrada de rastreamento em um disco de memória/unidade de sistema hospedeiro 126.
[00110] A Figura 4 é um diagrama de blocos 400 que indica a atividade de rastreamento de exemplo para um evento de rastreamento de acesso direto à memória (DMA) executado pelo sistema 100. Para o rastreamento de DMA, os dados para um exemplo de operação de DMA originária de um primeiro nó de processador para um segundo nó de processador podem trafegar através do ICI 112 e podem gerar saltos intermediários de ICI/roteador ao longo do caminho de dados. A operação de DMA gerará entradas de rastreamento em cada nó dentro de um chip do processador e ao longo de cada salto, à medida que a operação de DMA atravessa o ICI 112. As informações são capturadas por cada uma dessas entradas de rastreamento geradas para reconstruir uma progressão temporal das operações de DMA ao longo dos nós e saltos.
[00111] Um exemplo de operação DMA pode ser associado às etapas do processo representadas na implementação da Figura 4. Para esta operação, um DMA local transfere dados de uma memória virtual 402 (vmem 402) associada a pelo menos um dos núcleos de processador 104, 106 a HBM 108. A numeração mostrada no diagrama 400 corresponde às etapas da tabela 404 e representa geralmente atividades na malha de nó 110 ou atividades iniciadas pela malha de nó 110.
[00112] As etapas da tabela 404 geralmente descrevem pontos de rastreamento associados. A operação de exemplo gerará seis entradas de rastreamento para este DMA. A etapa um inclui a solicitação inicial de DMA do núcleo de processador para a malha de nós 110, que gera um ponto de rastreamento na malha de nós. A segunda etapa inclui um comando de leitura no qual a malha de nó 110 pede ao núcleo de processador para transferir dados que geram outro ponto de rastreamento na malha de nó 110. A operação de exemplo não possui uma entrada de rastreamento para a etapa três quando o vmem 402 completa uma leitura da malha de nó 110.
[00113] A etapa quatro inclui a malha de nó 110 executando uma atualização de recurso de leitura para causar uma atualização de sinalizador de sincronização no núcleo de processador que gera um ponto de rastreamento no núcleo de processador. A etapa cinco inclui um comando de gravação no qual a malha de nó 110 notifica a memória mux 108 dos dados a serem gravados no HBM. A notificação por meio do comando de gravação gera um ponto de rastreamento na malha de nó 110, enquanto na etapa seis, a conclusão da gravação no HBM também gera um ponto de rastreamento na malha de nó 110. Na etapa sete, a malha de nó 110 executa uma atualização de recurso de gravação para causar uma atualização de sinalizador de sincronização no núcleo de processador que gera um ponto de rastreamento no núcleo de processador (por exemplo, no FPC 104). Além da atualização do recurso de gravação, a malha de nó 110 pode executar uma atualização de confirmação (“ack update”) onde a conclusão de dados para a operação de DMA é sinalizada de volta ao núcleo de processador. A atualização do ack pode gerar entradas de rastreamento que são semelhantes às entradas de rastreamento geradas pela atualização do recurso de gravação.
[00114] Em outro exemplo de operação DMA, uma primeira entrada de rastreamento é gerada quando uma instrução DMA é emitida em uma malha de nó 110 do nó de origem. Podem ser geradas entradas de rastreamento adicionais na malha de nó 110 para capturar o tempo utilizado para ler dados para o DMA e gravar os dados em filas de saída. Em algumas implementações, a malha de nó 110 pode empacotar dados de DMA em partes menores de dados. Para dados empacotados em partes menores, entradas de rastreamento de leitura e gravação podem ser produzidas para um primeiro bloco de dados e um último bloco de dados. Opcionalmente, além do primeiro e do último bloco de dados, todos os fragmentos de dados podem ser configurados para gerar entradas de rastreamento.
[00115] Para operações de DMA remotas/não locais que podem requerer saltos ICI, os primeiros dados e o último fragmento de dados podem gerar entradas de rastreamento adicionais nos pontos de entrada e saída em cada salto intermediário ao longo do ICI/roteador 112. Quando os dados de DMA chegam a um nó de destino, são geradas entradas de rastreamento semelhantes às entradas de malha de nó anterior (por exemplo, leitura/escrita do primeiro e último fragmentos de dados) no nó de destino. Em algumas implementações, uma etapa final da operação de DMA pode incluir instruções executadas associadas ao DMA, causando uma atualização em um sinalizador de sincronização no nó de destino. Quando o sinalizador de sincronização é atualizado, uma entrada de rastreamento pode ser gerada indicando a conclusão da operação de DMA.
[00116] Em algumas implementações, o rastreamento de DMA é iniciado pelo FPC 104, SPC 106 ou HIB 114 quando em cada componente está no modo de rastreamento, para que os pontos de rastreamento possam ser executados. Os componentes de sistema 100 podem entrar no modo de rastreamento com base nos controles globais no FPC 104 ou SPC 106 através de um mecanismo de gatilho. Os pontos de rastreamento são acionados em resposta à ocorrência de uma ação ou condição específica associada à execução de código de programa pelos componentes de sistema 100. Por exemplo, porções do código de programa podem incluir funções de gatilho incorporadas que são detectáveis por pelo menos um componente de hardware de sistema 100.
[00117] Os componentes de sistema 100 podem ser configurados para detectar uma função de gatilho associada a porções de código de programa executadas por pelo menos um dos FPC 104 ou SPC 106. Em alguns casos, a função de gatilho pode corresponder a pelo menos um dentre: 1) uma determinada etapa de sequência em uma porção ou módulo do código de programa executado; ou 2) um parâmetro de tempo específico indicado pelo GTC utilizado pelas unidades de processador distribuídas de sistema 100.
[00118] Responsivo a detectar a função de gatilho, um componente específico de sistema 100 pode iniciar, disparar ou executar pelo menos um ponto de rastreamento (por exemplo, um evento de rastreamento) que faz com que os dados de entrada de rastreamento associados a um ou mais eventos de hardware sejam armazenados em pelo menos um buffer de memória do componente de hardware. Como notado acima, os dados de rastreamento armazenados podem então ser fornecidos ao gerenciador de chip 216 por meio de pelo menos uma cadeia de rastreamento 203, 205, 207.
[00119] Como notado acima, as Figuras 1-4 ilustraram abordagens para rastreamento de eventos de hardware em um sistema de computação distribuído. As restantes Figuras 5-7 descrevem abordagens para coleta de eventos de hardware sincronizado em um sistema de computação distribuído. A coleta sincronizada de eventos de hardware pode ser baseada, pelo menos em parte, em um ou mais mecanismos de gatilho.
[00120] A Figura 5 ilustra um exemplo de estrutura de dados para um contador de tempo global (GTC) 502 e tabelas 504 e 506 que indicam cenários de uso do GTC 502 por um sistema de computação de exemplo para rastreamento de hardware distribuído (por exemplo, sistema 100). Na implementação da Figura 5, o GTC 502 é um valor de 64 bits que inclui um contador de 60 bits e um deslocamento de 4 bits. Em implementações alternativas, o GTC 502 pode ser um pedaço fixo de dados binários tendo um tamanho, em bits, que varia de menos de 64 bits a mais de 64 bits.
[00121] A estrutura de dados associada ao GTC 502 aplica-se a um contador mestre global, bem como a contadores de tempo locais (LTCs) descritos abaixo, com referência à implementação da Figura 6. Os 60 bits superiores do GTC 502 correspondem a um contador de tempo real que aumenta em um por ciclo, exceto quando "alcançando" ou "pegando" para tratar as variações de fase GTC (descritas abaixo). Por exemplo, durante a atualização de um GTC 502 local (ou seja, um LTC), é possível que o GTC 502 local não “marque” por vários ciclos para “capturar” um GTC global mestre 502. Nesses cenários, os quatro bits inferiores “deslocamento” são usados para compensar as variações de fase do GTC que podem ocorrer durante a execução do código de programa.
[00122] Ao endereçar variações de fase GTC, os últimos quatro bits podem ser incrementados nessas circunstâncias para, em parte, manter a diferenciação entre carimbos de hora para atividades de eventos de hardware locais cujos GTCs seriam idênticos. Na maioria dos outros casos, o deslocamento de 4 bits do GTC 502 é limpo e, portanto, não utilizado. Em algumas implementações, os bits de deslocamento podem contar até 15 e depois parar. Enquanto, em implementações alternativas, os bits de deslocamento podem contar para qualquer valor inteiro conforme necessário por um projeto de contador específico. Em alguns casos, os bits de deslocamento são apagados quando os 60 bits superiores do GTC 502 começam a funcionar novamente.
[00123] No que diz respeito à configuração e gestão do GTC 502, 602 (descrito abaixo), em algumas implementações, o código de programa executado pode configurar ou preparar um GTC configurando um ou mais chips de processador de sistema 100. A configuração dos chips do processador pode incluir a designação de um GTC mestre global para o sistema, bem como a designação de GTCs locais (isto é, LTCs) para os respectivos nós ou componentes de sistema 100.
[00124] Os componentes podem incluir botões/recursos de hardware que a execução de código de programa/software usa para calcular e compensar latências de relógio e para executar o ajuste manual de um ou mais GTCs locais (isto é, LTCs da Figura 6). A compensação de LTC para latências de relógio e ajuste manual são pré-formadas em relação ao GTC mestre, para minimizar ou atenuar as variações de fase. Em algumas implementações, o sistema 100 pode incluir um modo de piloto automático para compensação de latência em que os recursos de hardware do componente determinam latências de enlace automaticamente por meio de um mecanismo de “ping e eco”.
[00125] Em algumas implementações, o sistema 100 pode incluir uma pilha de enlace/software que inclui uma porção, ou subconjunto, do código de programa usado para ajustar valores de parâmetros de um exemplo de registro de controle/estado (CSR). Em alguns casos, os sinais de controle gerados em resposta à execução do código de programa de pilha de enlace fazem com que um ou mais valores de parâmetros sejam gravados no CSR. Esses valores de parâmetro CSR podem ser usados para configurar vários aspectos do GTC 502, 602 ou LTCs.
[00126] Por exemplo, um ou mais parâmetros podem incluir: 1) um parâmetro GTC_config que causa a seleção de um GTC global mestre, GTC mestre local ou um GTC escravo local, e a seleção de um tamanho de amostra de atualização; 2) um parâmetro GTC_sync usado para redefinir um GTC mestre ou limpar uma medição “ping”; 3) um parâmetro GTC_latency_compensation_control que configura compensações manuais de latência; 4) um parâmetro GTC_enlace_ping que indica uma latência mínima de ping; 5) um parâmetro GTC_count que indica um valor GTC real; e/ou 6) um parâmetro GTC_max_diff que indica uma diferença máxima observada entre um GTC local e o GTC mestre.
[00127] Como indicado acima, um GTC mestre global 502 e um ou mais GTCs locais 502 podem ser utilizados pelo sistema 100 para obter carimbos de hora de evento e para determinar a ordem sequenciada entre eventos de hardware ocorrendo dentro de sistema. Além da ordem entre as atividades, o GTC 502 pode ser usado para determinar as latências das atividades. Em algumas implementações, um determinado GTC 502 pode exibir variações de fase, portanto, latências determinadas podem ser imprecisas por um ou mais ciclos.
[00128] Como indicado acima, a taxa na qual certos incrementos de GTC 502 podem variar dependendo se um GTC local é diferente do mestre global, isto é, quando há variações de fase. Em um estado estacionário, quando não há variações de fase, um GTC global mestre 502 incrementa uma vez por ciclo e pode ser usado para contar latências e ordem de atividades locais (por exemplo, de um determinado componente) tão bem quanto um LTC de componentes específico.
[00129] Em algumas implementações, um mestre GTC 502 pode contar mais lento que um certo LTC. Nestes casos, os bits de deslocamento do GTC 502 continuam sendo incrementados uma vez por ciclo de relógio local. Como indicado pelas tabelas 504, 506, por causa da funcionalidade única dos bits de deslocamento do GTC, um GTC estendido (“GTC-ext”) pode ser definido para uso pelo sistema 100. Em algumas implementações, o GTC-ext pode ser construído adicionando os 60 bits superiores (GTC:topo) e os quatro bits de deslocamento inferiores (GTC: deslocamento), enquanto em outras implementações, o código de programa executando em um processador específico pode calcular GTC-ext para igual a GTC:topo somado com um GTC fracionário: valor de deslocamento.
[00130] Em algumas implementações, e em resposta ao incremento dos bits de deslocamento, um parâmetro GTC-ext pode ser usado para determinar a ordenação de eventos, bem como as latências das operações locais. As tabelas 504, 506 indicam cenários de uso nos quais o parâmetro GTC-ext pode ser útil ao determinar a ordenação de eventos de hardware e a latência das operações de eventos.
[00131] A Tabela 504 descreve o uso do GTC de exemplo para determinar a ordem entre atividades ou eventos de hardware. Em algumas implementações, a taxa na qual um GTC 502 incrementa, durante o curso de uma atividade sendo analisada, pode não ser relevante ao usar o GTC 502 para determinar a ordem global, por exemplo, a ordem de uma ou mais atividades entre pelo menos dois nós de computação (por exemplo, nós distintos que possuem um GTC mestre). No entanto, quando um GTC local 502 em um determinado nó é mais lento do que o GTC mestre de nós, GTC-ext pode ser usado para diferenciar entre duas atividades locais ou entre quando duas atividades locais iniciam gravações em recursos remotos, conforme mostrado pelo recurso 508 da tabela 504.
[00132] A Tabela 506 descreve o uso do GTC de exemplo para calcular a latência de atividades/eventos locais ou atividades que abrangem dois ou mais nós. Em algumas implementações, os parâmetros de sistema podem não indicar se um GTC 502 em um determinado chip está funcionando a uma taxa normal (ou seja, em sincronia com um relógio global mestre designado) ou passando em uma taxa que está fora da fase do mestre global designado. Assim, em alguns casos, o LTC pode ser usado para a determinação de latência de eventos de atividades locais, conforme mostrado pelo recurso 510 da tabela 506. Enquanto, em outras implementações, GTC ou GTC-ext pode ser usado para medir latências de uma ou mais operações.
[00133] Em geral, os eventos de rastreamento de hardware que ocorrem em vários nós ou componentes de sistema 100 podem incluir um parâmetro GTC. Em algumas implementações, quando os eventos/atividades de hardware rastreados abrangem vários nós de sistema 100, as latências associadas às atividades locais devem ser calculadas via GTC em vez de um LTC. Nessas implementações, o uso de GTC ou GTC-ext pode ser a solução preferida de contador/relógio, pois os LTCs em dois ou mais nós distintos podem não ser sincronizados ou com contados/marcados na mesma taxa.
[00134] A Figura 6 ilustra um diagrama de blocos de exemplos de contadores de tempo e um ou mais contadores associados aos respectivos componentes de um sistema de computação de exemplo para rastreamento de hardware distribuído (por exemplo, sistema 100). Os contadores de tempo podem incluir o contador de tempo global (GTC) 602 e vários contadores de hora local (LTC), cada um associado aos respectivos componentes de sistema 100.
[00135] Para clareza, embora a Figura 6 representa um único bloco LTC acoplado a componentes específicos de sistema 100, em implementações alternativas, cada componente pode incluir um ou múltiplos contadores de tempo local/LTCs. Além disso, embora a Figura 6 representa um único GTC mestre 602, esse recurso também pode corresponder, ou ser representativo de um LTC específico que é selecionado para funcionar como o mestre global. Por exemplo, em algumas implementações, o GTC 602 corresponde à lógica de seleção de contador implementada pelo sistema hospedeiro 126 para selecionar um LTC específico para funcionar como um relógio/contador mestre global.
[00136] Em alguns casos, o sistema 100 pode selecionar um nó de exemplo do ICI 112 para funcionar como um relógio principal global e os LTC do nó de exemplo marca por um ciclo de relógio. Enquanto, em implementações alternativas, o GTC 602 é um contador de tempo global que funciona como um relógio mestre global e que difunde um parâmetro de tempo específico para os componentes de sistema 100. Em qualquer implementação, o GTC 602 pode ser um relógio globalmente síncrono usado para correlacionar eventos de hardware que ocorrem no sistema 100.
[00137] Em algumas implementações, como descrito acima, o GTC 602 pode ter pequenas variações de fase no sistema 100, mas pode ser configurado para evitar o desvio de tempo a longo prazo. Por exemplo, o GTC 602 pode marcar ou contar com base em um exemplo de oscilador de um determinado chip do processador (por exemplo, um oscilador selecionado para ser o mestre global). Em geral, não há variações de desvio ou fase de longo prazo específicas para o oscilador selecionado de um chip de processador no sistema 100, no entanto, ao longo do tempo podem ocorrer desvios ou variações em relação aos osciladores entre chips de processador distintos. Assim, o GTC 602 pode incrementar (isto é, assinalar) mais rapidamente ou mais lentamente que um relógio local (LTC) em um chip de processador que não é o mestre global.
[00138] Como o mestre global, um valor mestre atual do GTC 602 pode ser transmitido para todos os nós do ICI 112. Exemplos de nós ICI podem corresponder a um ou mais componentes de sistema 100. Os nós de recepção podem calcular uma diferença entre seu valor local de um exemplo de GTC usado para operações locais específicas do componente/nó específico. Uma diferença mínima entre o valor mestre recebido e o valor GTC local durante um período de amostragem de exemplo pode ser usada para atualizar o GTC local. Com o passar do tempo, as variações de fase entre o valor mestre e os valores GTC locais, se houver, podem ser "captadas" com base nos ajustes de contador implementados usando um ou mais bits de deslocamento discutidos acima.
[00139] Como mostrado na implementação da Figura 6, os componentes de sistema 100 podem cada um incluir um ou mais contadores de desempenho, e conjuntos coletivos, ou subconjuntos, de contadores de desempenho dentro de sistema 100 são aqui descritos como múltiplos contadores 600. Em particular, e específico para cada componente, o FPC 104 pode incluir múltiplos contadores 604, o SPC 106 pode incluir múltiplos contadores 606, memória mux (HBM) 108 pode incluir múltiplos contadores 608, a malha de nó 110 pode incluir múltiplos contadores 610, ICI 112 pode incluir múltiplos contadores 612 e HIB 114 podem incluir múltiplos contadores 614.
[00140] No sistema 100, a análise de desempenho do código de programa executado por um ou mais processadores pode ser ativada/desativada com base no uso de um ou mais contadores de desempenho de hardware associados a componentes específicos do sistema. Estes contadores de desempenho podem corresponder aos múltiplos contadores respectivos da Figura 6 e pode incluir pelo menos um dos seguintes: 1) contadores de atividade; 2) contadores de paralisação; 3) contadores estatísticos; e 4) contadores de amostragem.
[00141] Em algumas implementações, o sistema 100 inclui vários outros tipos de contadores de desempenho que podem ser programados para incrementar e armazenar dados de contagem especificados associados a aspectos técnicos do código de programa de execução. Além disso, através do uso de um ou mais contadores, o suporte de hardware para a atividade de rastreamento pode incluir funções relacionadas a, por exemplo: captura de dados de eventos de rastreamento de instruções; captura de dados de eventos de mux de rastreamento de memória; captura de dados de eventos de rastreamento de DMA; e captura de dados do evento em buffers de rastreamento.
[00142] Em algumas implementações, pelo menos um subconjunto de múltiplos contadores 600 pode ser CSRs ou contar registros que são acessíveis pelo sistema hospedeiro 126 via HIB 114. Esses registros de contagem/CSRs podem ser dispositivos de armazenamento configurados para armazenar vários tipos de dados/informações de contagem que identificam instruções recebidas, processadas ou executadas por um componente de hardware específico, bem como uma variedade de outros tipos de dados/informações associados a aspectos técnicos da execução do código de programa. Em alguns casos, os dados são armazenados nas contagens ou incrementos de formulários associados a instruções específicas ou operações do processador (por exemplo, um parâmetro de contagem). Em algumas implementações, vários contadores 600 de sistema 100 podem corresponder a centenas ou milhares de contadores de desempenho/registros de contagem.
[00143] Com relação aos pelo menos quatro tipos de contadores de desempenho observados acima, em algumas implementações, os contadores de atividade podem ser usados para armazenar e analisar dados associados a parâmetros de utilização para diferentes unidades de hardware. Os contadores de atividade também podem ser usados para analisar porções do código de programa de execução ou para analisar quantidades ou tipos de dados que estão sendo transferidos durante a execução do código. Por exemplo, alguns núcleos de processador podem incluir contadores de atividade que são usados para derivar a combinação de instruções em vários fluxos de instruções. Por exemplo, um contador de atividades pode ser configurado para armazenar contagens associadas à execução de tipos de instruções específicas em um fluxo de instruções de exemplo.
[00144] Em algumas implementações, os contadores de atividades podem incluir subconjuntos de contadores, como: contadores de ocorrências que são incrementados após a emissão de certos tipos de instrução; contadores de atividade de memória que estão disponíveis em caminhos de memória e que são incrementados em resposta a, por exemplo, leituras/gravações associadas a transferências de memória entre (por exemplo, entre mux 108 e um VMEM 402); e um ou mais outros contadores de atividades gerais que são incrementados em resposta à ocorrência de instruções, como interrupções, sinalizadores de sincronização e contadores de alarme.
[00145] Em relação aos contadores de paralisação, em algumas implementações, esses contadores podem fornecer contagens de paralisação indicando um número de ciclos que uma certa unidade/componente de hardware foi parada devido a um motivo de paralisação específico, em vez de fazer um trabalho útil associado ao processamento de instruções ou cálculos de dados. Por exemplo, quando a utilização de uma determinada unidade de hardware está abaixo de uma utilização de limite, ou o código de programa não está executando em um nível de desempenho de limite desejado, os contadores de paralisação podem ser usados pelo sistema 100 para obter informações pertinentes de paralisação para a análise da causa-raiz de problema de utilização e desempenho (por exemplo, abaixo do limite de utilização/desempenho).
[00146] Em algumas implementações, os contadores de paralisação podem fornecer informações pertinentes relacionadas a: paralisações com base na detecção de certos caminhos de memória normalmente disponíveis que são indicados como indisponíveis; paralisações com base na execução atrasada de uma ou mais instruções de sinalização de sincronização; e/ou paralisações devido a uma ou mais unidades de execução normalmente disponíveis (por exemplo, XU 122 ou RPU 124) que estão indicadas como indisponíveis.
[00147] Em algumas implementações, o FPC 104 pode incluir pelo menos uma unidade escalar que fornece grandezas escalares para cálculos vetorizados realizados pela VPU 118. Os contadores de paralisação associados à unidade escalar podem fornecer informações pertinentes para as paralisações que são causadas por um ou mais perigos que podem ocorrer dentro da unidade escalar. Em alguns casos, vários tipos de perigo podem ocorrer e o FPC 104 pode incluir contadores de paralisação para cada tipo de perigo. Exemplos de tipos de perigo podem incluir riscos de atraso de DMA, perigos de atraso de cerca escalar e/ou risco de instrução de atraso escalar.
[00148] Em relação aos contadores estatísticos, em algumas implementações, os componentes de sistema 100 podem incluir uma ou mais filas de dados (por exemplo, meios de armazenamento) e os contadores de atividade podem ser configurados para fornecer informações relacionadas à utilização da fila. No entanto, em alguns casos, os contadores de atividade das filas podem não ser suficientes para fornecer todas as informações sobre como as filas estão sendo bem utilizadas ao executar o código de programa. Nesses casos, os contadores estatísticos podem estar disponíveis em um ou mais componentes para adquirir determinadas contagens de dados, de modo que os cálculos relacionados à ocupação média da fila e ao tempo gasto em certas filas possam ser determinados.
[00149] Em algumas implementações, os contadores estatísticos de filas podem fornecer contagens estatísticas relacionadas à ocupação da fila, estado de inserção da fila, estado completo da fila, ou fila no estado de ocupação do limite. Em alguns casos, quando o contador estatístico de fila está ativo, um contador de ocupação associado a uma fila de componentes é incrementado com base na ocupação atual da fila em cada ciclo de processador/instrução.
[00150] Em outros casos, quando um contador estatístico de fila ativa fornece contagens relacionadas ao estado completo da fila, o contador é incrementado (por exemplo, por um) em ciclos nos quais uma fila está totalmente ocupada. Além disso, quando um contador estatístico de fila ativa fornece contagens relacionadas ao estado de inserção de fila, o contador é incrementado em resposta a blocos de dados sendo colocados (ou seja, inserção de fila) na fila. Mais ainda, para a fila no estado de ocupação de limite, o contador pode incrementar (por exemplo, um) em cada ciclo em que a ocupação da fila atual é maior do que uma ocupação limite específica da fila.
[00151] Em algumas implementações, componentes de sistema 100 podem incluir conjuntos de contadores de amostragem que podem ser periodicamente lidos a partir de sistema hospedeiro 126 para gerar estruturas de dados (por exemplo, estruturas 320 ou 620). As estruturas de dados podem incluir estatísticas de amostra sobre eventos de hardware, atividade de rastreamento ou informações detalhadas de processamento de dados para atividades/eventos que ocorrem em unidades de processador distribuídas de sistema 100. Em algumas implementações, as estruturas de dados geradas com base nas estatísticas da amostra podem incluir, por exemplo, a estrutura 320 (descrita acima) ou a estrutura 620 (descrita abaixo). Em alguns casos, as estruturas de dados geradas são utilizadas para construir uma ou mais ferramentas de monitoramento usadas pelo mecanismo de monitoramento 128, de sistema hospedeiro 126, para analisar o desempenho do código de programa executado pelos componentes de sistema 100.
[00152] Como referido acima, os componentes de sistema 100 podem iniciar o rastreamento de eventos com base nos controles globais associados a um ou mais mecanismos de gatilho. Em algumas implementações, vários contadores 600 podem ser ativados, desativados ou controlados de outra forma para iniciar mecanismos de acionamento que fazem com que pontos de rastreamento sejam executados e gerem entradas de rastreamento, incluindo dados específicos relacionados a um ou mais eventos de hardware. Em algumas implementações, as entradas de rastreamento relacionadas a eventos de hardware são preenchidas com dados de evento baseados, pelo menos em parte, em dados de contagem agregados por um ou mais dos múltiplos contadores 600 descritos acima.
[00153] Os controles globais geralmente incluem o uso de controles de CSR (isto é, recursos/botões de hardware de CSR específicos), bem como mecanismos de gatilho que permitem incrementar contadores e permitir a geração de rastreamentos de maneira coordenada e sincronizada. Em algumas implementações, o controle coordenado e sincronizado pode ocorrer entre as unidades de processador distribuídas de sistema 100. Como discutido acima, o rastreamento sincronizado pode ser ativado, em parte, através do uso de um contador globalmente síncrono que é usado como um relógio mestre global (por exemplo, GTC 602).
[00154] Em algumas implementações, o sistema 100 aciona o rastreamento de eventos sincronizados com base em um determinado parâmetro de tempo indicado por um relógio de tempo global das unidades de processador distribuídas (por exemplo, o parâmetro de tempo 09: 01.13). Por exemplo, o sistema 100 pode usar os valores de relógio mestre global do GTC 602 como um gatilho para iniciar e parar todos os contadores e traçar com precisão a duração de uma determinada operação.
[00155] Em alguns casos, um exemplo de compilador de software de sistema 100 pode incorporar ou inserir, dentro do código de programa de execução, instruções incluindo operandos ou valores de parâmetros para um mecanismo de gatilho que é baseado em uma janela de tempo predefinida específica associada ao GTC 602. A janela de tempo predefinida pode incluir um exemplo de duração de rastreamento que possui um tempo de início de evento de rastreamento (por exemplo, um primeiro parâmetro de tempo GTC 602) e um tempo de término de evento de rastreamento (por exemplo, um segundo parâmetro de tempo GTC 602 que é posterior ao primeiro parâmetro de tempo GTC).
[00156] Como mostrado na implementação da Figura 6, os componentes de sistema 100 podem incluir múltiplos contadores de desempenho 600. No que se refere aos mecanismos de gatilhos, os controles de contador de desempenho podem incluir mecanismos para habilitar e desabilitar os contadores, além de limpar os contadores e pausar os contadores. Ainda, além das funções de contagem estatística descritas acima, algumas unidades de hardware podem incluir contadores estatísticos que possuem seletores associados (por exemplo, CSRs) usados para selecionar um subconjunto de blocos de hardware dentro da unidade de hardware cujos eventos são contados.
[00157] Como discutido acima com referência a rastrear controles de mux, em algumas implementações, o rastreamento pode ser ativado e desativado com base em gravações de CSR executadas pelo sistema 100. Em alguns casos, o rastreamento pode ser iniciado e parado dinamicamente, pelo sistema 100, com base no valor de um registro de marca de rastreamento (TM) de exemplo no FPC 104 (ou núcleo 116) ou com base no valor de um exemplo de registro TM em SPC 106.
[00158] Em algumas implementações, um parâmetro de controle de rastreamento de exemplo pode ser usado para definir uma janela de rastreamento específica. Por exemplo, o parâmetro de controle de rastreamento pode permitir que janelas de rastreamento sejam definidas em termos dos limites inferiores e superiores do GTC 602 (por exemplo, valores de horário de início e de tempo de parada) e limites inferior e superior de um registro de marca de rastreamento de exemplo no FPC 104 ou um exemplo de registro de marcas de rastreamento no SPC 106.
[00159] Em algumas implementações, o código de programa de execução no sistema 100 pode incluir lógica de processamento de gatilho para acionar eventos de rastreamento em cada ciclo do processador dentro de um dos FPC 104 ou SPC 106. Em alguns casos, a lógica do gatilho é associada a uma instrução especial “definir marca de rastreamento” que pode ser inserida, pelo código de software/programa em execução, em um ou mais fluxos de instrução.
[00160] Por exemplo, e em relação à lógica de gatilho do FPC 104, quando uma instrução de exemplo para definir uma marca de rastreamento é emitida dentro do FPC 104, a lógica de gatilho pode incluir a análise de um operando de marca de rastreamento da instrução e comparar um valor de parâmetro do operando para valores de uma janela de marcas de exemplo. Essa análise e comparação é usada para determinar se o valor do parâmetro do operando é igual a um valor de limite inferior ou se está dentro do valor do limite inferior e de um valor do limite superior de uma janela específica da marca de rastreamento.
[00161] Se um valor de parâmetro do operando estiver dentro dos limites da janela de marca de rastreamento, um gatilho pode ser acionado (por exemplo, condição de gatilho satisfeita) e o FPC 104 pode entrar em um modo de rastreamento ou contagem e habilitar um ou mais contadores de múltiplos contadores. Em algumas implementações, o FPC 104 sai do modo de rastreamento/contagem quando uma instrução subsequente “definir marca de rastreamento” inclui um valor de parâmetro de operando que faz com que um gatilho de contagem de parada seja acionado com base no valor do operando sendo igual ou fora do limite superior de uma janela de marca de rastreamento de exemplo.
[00162] Em algumas implementações, o sistema 100 pode detectar que uma condição de gatilho é satisfeita com base em pelo menos um dentre: i) identificação de uma ocorrência de um operando de marca de rastreamento de exemplo em pelo menos uma primeira porção do código de programa de execução. O operando de marca de rastreamento pode incluir um valor de parâmetro (por exemplo, uma sequência/valor de etapa de código) que é usado para iniciar um ou mais eventos de rastreamento e/ou contagem de desempenho. O sistema 100 também pode detectar que uma condição de gatilho é satisfeita com base na determinação de que uma hora atual GTC 602 indica um valor de tempo predefinido que é usado para iniciar um ou mais eventos de rastreamento e/ou contagem de desempenho.
[00163] Em resposta à detecção de que a condição de gatilho é satisfeita, um componente de processador de sistema 100 pode gerar um sinal de controle que é recebido por um registro de contagem do componente de processador. O sinal de controle pode fazer com que vários dados de contagem associados a um ou mais eventos de hardware sejam armazenados no registro de contagem. Em algumas implementações, o sistema 100 pode ser configurado ou programado para gerar, por exemplo, através de sistema hospedeiro 126, uma estrutura de dados que indica um ou mais atributos de desempenho associados ao código de programa de execução. Por exemplo, a estrutura de dados pode ser gerada com base em um ou mais parâmetros de contagem dos dados de contagem armazenados. Em algumas implementações, o registro de contagem é um dos múltiplos contadores de desempenho 600 configurados para armazenar dados de contagem sobre o desempenho de um ou mais componentes de processador do sistema 100.
[00164] Para ilustrar ainda mais o gatilho de marca de rastreamento, em uma sequência de código de exemplo, a instrução para definir marca de rastreamento pode incluir um operando de gatilho de 32 bits que identifica uma construção de software distribuído (por exemplo, uma etapa computacional em uma carga de trabalho de inferência de rede neural). O FPC 104 pode incluir um CSR com propósito especial, identificado no código de programa como "tracemark_limits". Embora operandos de 32 bits sejam descritos nesta sequência de código de exemplo, em implementações alternativas, operandos de gatilho ou operandos de limite de registro/valores de parâmetros podem ser estruturas de dados binários com menos de 32 bits ou mais de 32 bits.
[00165] Este CSR com finalidade especial pode codificar pelo menos dois valores de 32 bits. Um primeiro valor de 32 bits codificado pode corresponder a um limite de marca de rastreamento inferior usado para iniciar rastreamento/contagem, enquanto um segundo valor de 32 bits codificado pode corresponder a um limite de marca de rastreamento superior usado para interromper o rastreamento/contagem. Em algumas implementações, o primeiro e segundo valores codificados correspondem a etapas computacionais em um programa/construção de software distribuído, como um exemplo de carga de trabalho de inferência de rede neural ou qualquer outro código de programa distribuído.
[00166] Referindo-se novamente à sequência de código de exemplo, quando a instrução “definir marca de rastreamento” é executada, o valor do operando de 32 bits é comparado ao primeiro e segundo valores codificados no registro tracemark_limits. Com base nessa comparação, se o operando de gatilho for igual/igualar ou tiver um valor maior que o valor inicial (isto é, o primeiro valor codificado), a atividade de análise de desempenho será acionada. Da mesma forma, se o operando de gatilho corresponder ou tiver um valor maior que o valor de parada (isto é, o segundo valor codificado), a atividade de análise de desempenho contínua será interrompida.
[00167] Assim como o gatilho de marca de rastreamento, quando o GTC 602 é usado como gatilho (por exemplo, para FPC 104 ou SPC 106), os limites superior e inferior dos registros de gatilho GTC/LTC de exemplo para um componente específico podem ser avaliados contra um valor atual de GTC 602. Portanto, um parâmetro de hora atual ou valor de GTC 602 pode ser comparado a um limite inferior de uma janela de tempo pré-definida de exemplo para executar a atividade de rastreamento usando um gatilho GTC. Da mesma forma, após a execução do gatilho GTC para começar a contagem de atividade, um parâmetro de hora atual ou valor de GTC 602 pode ser comparado ao limite superior do registro de gatilho GTC para determinar se o GTC 602 corresponde ou está fora do valor limite superior. Em resposta ao GTC 602 que corresponde pelo menos ao valor do limite superior, um gatilho de contagem de parada será acionado para fazer com que o componente saia do modo de contagem.
[00168] Em algumas implementações, o SPC 106 inclui uma contraparte à instrução de definir marca de rastreamento do FPC 104. Assim, a lógica de processamento de gatilho para o SPC 106 pode funcionar da mesma maneira, ou substancialmente similar, como no FPC 104. Por exemplo, um parâmetro de marca de rastreamento pode ser incluído como um operando em uma ou mais instruções emitidas pelo SPC 106. Em alguns casos, a avaliação do gatilho do operando ocorre em cada questão da instrução, e a lógica de avaliação pode ser substancialmente similar à maneira pela qual a contagem é habilitada no FPC104 (por exemplo, usando um operando de marca de rastreamento). Por exemplo, no SPC 106, quando um operando de marca de rastreamento incluído em uma instrução de marca de rastreamento está dentro dos limites inferior e superior de uma janela de rastreamento de exemplo, o rastreamento é habilitado. Da mesma forma, quando o operando de marca de rastreamento incluído na instrução de marca de rastreamento está fora dos limites inferior e superior da janela de rastreamento, o rastreamento é desabilitado.
[00169] Como discutido acima, além de usar GTC 602 ou marcadores de rastreamento, o sistema 100 pode incluir um modo de rastreamento de "todos". Em geral, o modo de rastreamento de todos pode fazer com que o rastreamento através de todo um chip de processador seja controlado, por exemplo, por um sinal de controle gerado por um componente do FPC 104 ou SPC 106. Em algumas implementações, o sinal de controle pode ser um parâmetro de controle global que indica um estado de desempenho específico das unidades de processador distribuídas de sistema 100. Em alguns casos, o estado de desempenho específico corresponde ao modo de rastreamento de "todos".
[00170] Em algumas implementações, um ou mais componentes de hardware (por exemplo, HIB 114 ou ICI 112) podem ser programados ou configurados para iniciar o rastreamento de eventos em resposta à ativação do modo de rastreamento de “todos” ou simplesmente ignorar um sinal de controle de propagação indicando o modo de rastreamento de todos. Assim, embora o sistema 100 possa incluir um mecanismo de sinalização para propagar um sinal de controle de rastreamento de todos, o sistema 100 também pode incluir mecanismos para fazer com que pelo menos um componente de hardware ignore o sinal de controle.
[00171] Por exemplo, um usuário (por exemplo, um analista de desempenho) de sistema 100 pode querer usar o HIB 114 para rastrear pacotes de dados que indicam todas as comunicações de hospedeiros. O usuário pode inserir, por exemplo, através de um compilador externo, uma instrução de programa de exemplo para fazer com que o HIB 114 entre em um modo “sempre rastrear”, enquanto também usa o modo de rastreamento de todos para capturar certas sequências de dados de outros componentes de hardware de sistema 100. Portanto, quando programado para executar no modo de rastreamento sempre, o HIB 114 pode desconsiderar o sinal de controle de rastreamento de todos usados para gerar dados de rastreamento de sequência de etapa única a partir de outros componentes de hardware.
[00172] Em algumas implementações, os pontos de rastreamento podem ser acionados em resposta à ocorrência de uma ação ou condição específica relacionada à execução do código de programa pelos componentes de sistema 100. Por exemplo, um programa de software distribuído pode incluir vários módulos de software que incluem sequências ou etapas de código compartilhadas ou sobrepostas. Por exemplo, os núcleos de processador 104, 106 podem cada um receber e executar porções de um programa de software distribuído e cada porção de programa pode incluir uma sequência de código de exemplo 1-100.
[00173] Como indicado acima, em algumas implementações, o sistema 100 pode ser configurado para incluir uma ou mais condições/mecanismos de gatilho que têm, ou que são baseados em, uma etapa de sequência específica do código de programa distribuído. Assim, o sistema 100 pode ser configurado para disparar um ponto de rastreamento em resposta a cada um dos núcleos de processador 104, 106 que chegam a uma determinada sequência/etapa codificada (por exemplo, etapa de sequência de código 33) durante a execução de código. Em alguns casos, porções do código de programa distribuído executado podem incluir funções de gatilho incorporadas que são detectáveis por pelo menos um componente de hardware de sistema 100.
[00174] Por exemplo, como observado acima, o sistema 100 pode ser configurado para detectar que uma ou mais condições de gatilho são satisfeitas com base na identificação de ocorrências de operandos em pelo menos uma porção do código de programa executada por um do FPC 104 ou SPC 106. Responsivo a detectar que pelo menos uma condição de gatilho é satisfeita, o sistema 100 pode iniciar um ou mais eventos de rastreamento que geram entradas de rastreamento/dados de rastreamento ou dados de contagem. Em algumas implementações, as entradas de rastreamento geradas podem incluir pelo menos um atributo que é compartilhado entre os respectivos eventos de hardware que ocorrem nas unidades de processador distribuídas (por exemplo, um carimbo de hora compartilhado ou etapa de sequência de código).
[00175] Por exemplo, e como mostrado pela estrutura de dados 620, entradas de rastreamento geradas 622 podem corresponder a um evento de rastreamento sincronizado e os dados de rastreamento podem incluir identificadores de rastreamento exclusivos para os respectivos eventos de hardware e um carimbo de data/hora de evento de hardware global (por exemplo, 09:01.13) entre pelo menos dois eventos de hardware respectivos. Assim, para entradas de rastreamento 622, pelo menos um atributo compartilhado entre os respectivos eventos de hardware pode ser o carimbo de hora do evento de hardware. Do mesmo modo, quando o sistema 100 aciona pontos de rastreamento com base em uma sequência de código específica, para entradas de rastreamento 624 pelo menos um atributo que é compartilhado entre os respectivos eventos de hardware pode ser a sequência de código ou a etapa de marca de rastreamento.
[00176] Em algumas implementações, as entradas de rastreamento podem incluir um cabeçalho ou um campo de carimbo de hora. O cabeçalho de carimbo de hora pode incluir um carimbo de hora de 48 bits que identifica o horário em que a entrada de rastreamento foi gerada. Em alguns casos, o cabeçalho do carimbo de hora pode corresponder a menos de 48 bits do GTC 502.
[00177] Como indicado acima, em algumas implementações, um compilador de sistema 100 pode inserir um ou mais operandos para múltiplas condições de gatilho em porções de código de programa executadas por núcleos de processador de exemplo de sistema 100. Por exemplo, um compilador associado ao FPC 104 pode inserir ou incorporar um ou mais operandos para condições de gatilho em porção do código de programa executado pelo FPC 104. Da mesma forma, um compilador associado ao SPC 106 pode inserir ou incorporar um ou mais operandos para condições de gatilho em porções do código de programa executado pelo SPC 106.
[00178] Em geral, e como observado acima, o sistema 100 é configurado para detectar as condições de um ou mais gatilhos e, responsivo a detectar as condições, iniciar pelo menos um evento de rastreamento. Em algumas implementações, iniciar o pelo menos um evento de rastreamento pode incluir o sistema 100 fornecendo, por exemplo, um primeiro sinal de controle a um primeiro contador/registro de desempenho (por exemplo, um CSR como um contador de atividade) do FPC 104. Esse primeiro sinal de controle pode fazer com que os dados associados a pelo menos um evento de hardware seja armazenado no primeiro contador de desempenho.
[00179] Do mesmo modo, em algumas implementações, iniciar o pelo menos um evento de rastreamento pode incluir ainda o sistema 100 fornecendo, por exemplo, um segundo sinal de controle a um segundo contador/registro de desempenho (por exemplo, um CSR como um contador estatístico) do SPC 106. Esse segundo sinal de controle pode fazer com que os dados associados a pelo menos um evento de hardware seja armazenado no segundo contador de desempenho.
[00180] Em algumas implementações, os dados associados ao pelo menos um evento de hardware pode incluir um dentre: 1) um número de bytes escritos para um buffer de memória específico de um certo núcleo de processador das unidades de processador distribuídas de sistema 100; ou 2) um número de instruções executadas por um certo núcleo de processador das unidades de processador distribuídas de sistema 100.
[00181] Em geral, o sistema de rastreamento descrito inclui mecanismos de ação de gatilho baseadas em hardware. Os gatilhos podem ser configurados antes para disparar com base na semântica do software. Por exemplo, operandos para condições de gatilho podem ser inseridos ou incorporados em prólogos e epílogos de componentes de software (por exemplo, em funções, cabeçalhos de loop ou outros locais oportunos em um sistema de software distribuído). Como observado acima, em alguns casos, a inserção de operandos para condições de gatilho é feita por um compilador no sistema 100, enquanto em outras instâncias, gatilhos e operandos de gatilho podem ser incorporados/inseridos por programadores antes da execução do código pelo sistema 100, ou podem ser incorporados, durante a execução de código em tempo real, pelo sistema hospedeiro 126.
[00182] Por exemplo, em algumas implementações, uma condição indicando quando o gatilho é para disparar pode ser configurada através de um sistema de hardware distribuído (por exemplo, em cada chip/nó de sistema 100) pelo software de análise de desempenho em execução no sistema hospedeiro 126. Quando o gatilho é acionado, o rastreamento de hardware e a contagem de desempenho são realizados em uma unidade de hardware específica, e condições de gatilho semelhantes são configuradas para interromper a coleta de dados de rastreamento.
[00183] Em outras implementações, um gatilho no sistema 100 pode ser um valor crescente monotonicamente que é um operando para uma instrução. A instrução pode ser inserida em prólogos e epílogos de importantes construções de software por um compilador de exemplo de um núcleo de processador. Em geral, há uma penalidade insignificante de desempenho, para o código de programa de execução, ter o operando de gatilho na instrução sempre presente, pois os dados de desempenho não são coletados até que um gatilho seja disparado.
[00184] Por exemplo, uma condição de gatilho pode ser configurada gravando em um registro de exemplo em um componente de hardware. Para avaliar ou detectar o gatilho, cada vez que uma instrução de gatilho é encontrada, o componente de hardware pode comparar o valor nesse registro com o valor de operando da condição de gatilho na instrução. Geralmente, uma condição de gatilho deve ser configurada bem antes de certas etapas de sequência codificadas, de forma que nenhum dos chips/nós do processador no sistema distribuído chegue antecipadamente à condição de gatilho.
[00185] Em alguns casos, a implementação do gatilho de hardware requer a propagação de um sinal de gatilho dentro de componentes diferentes de um chip/nó de processador de exemplo. Pelo menos um benefício do mecanismo de ação de gatilho permite que um programa de software distribuído execute uma atividade (por exemplo, etapa de sequência de código 33) em um primeiro nó em um tempo muito diferente de uma atividade relacionada (por exemplo, etapa de sequência de código 33) em outro (segundo) nó. Nesta implementação, o sistema 100 pode manter a coleta precisa de dados de desempenho de hardware para atividades idênticas ou substancialmente relacionadas que são executadas por diferentes componentes de hardware ou nós de processador em diferentes períodos de tempo.
[00186] Em algumas implementações, um caso de uso de gatilho de exemplo pode incluir o sistema 100 que coleta vários conjuntos de dados de rastreamento sem reprogramar, redefinir ou reinserir uma condição de gatilho específica. Por exemplo, o código de programa de execução pode incluir construções de software que geram uma sequência de instruções na qual o mesmo operando para definir uma marca de rastreamento aparece várias vezes. Em alguns casos, o mesmo operando de marca de rastreamento configurado pode aparecer várias vezes quando um processador de sistema 100 executa uma determinada porção do código de programa em um loop. Durante a execução de um loop de programa, o rastreamento de evento pode começar e terminar de acordo com as iterações do loop de programa.
[00187] Por exemplo, uma condição de gatilho pode ser satisfeita, por exemplo, acionamentos de gatilhos e início de rastreamento de eventos, com base em um valor de operando que aparece no início de uma iteração de loop. Da mesma forma, uma condição de gatilho pode não ser mais satisfeita, por exemplo, o rastreamento de eventos é interrompido, com base em um valor de operando que aparece no final da iteração do loop. Em geral, o início de uma iteração de loop e o final de uma iteração de loop podem corresponder aos limites de um loop de programa para uma determinada construção de software. Portanto, uma sessão de rastreamento pode começar e terminar em cada execução da construção do software (por exemplo, cada iteração de loop).
[00188] Em algumas implementações, valores adequados de operandos de gatilho (por exemplo, GTC ou marca de rastreamento) podem ser determinados da seguinte maneira. Como observado acima, um programa de software distribuído pode incluir módulos de software que incluem sequências ou etapas de código compartilhadas ou sobrepostas. Durante a execução do código de programa distribuído no sistema 100, um analista de desempenho pode ler ou analisar, através de um console de computação de sistema 100, um valor de CSR de um registro de marca de rastreamento para determinar, por exemplo, uma sequência de código ou número de etapa atual.
[00189] Em alguns casos, o analista lê repetidamente o valor do CSR para determinar uma taxa média de aumento da sequência ou etapas. A taxa determinada de aumento pode ser usada para definir preditivamente uma ou mais condições de gatilhos com base em ocorrências de, por exemplo, valores de um operando de marca de rastreamento. Em algumas implementações, ao usar o GTC, um analista de desempenho pode ler ou analisar a velocidade de relógio de sistema/máquina (ou componente de hardware) para prever ou determinar uma taxa na qual o GTC aumenta. O analista pode então usar a taxa determinada para definir uma ou mais condições de gatilho com base na ocorrência de um determinado valor de GTC.
[00190] A Figura 7 é um diagrama de fluxo de processo de um processo de exemplo 700 para rastreamento de hardware distribuído utilizando o sistema de computação 100 e um ou mais nós 200, 201 de sistema 100. Assim, o processo 700 pode ser implementado utilizando um ou mais dos recursos de computação acima mencionados de sistemas 100, incluindo recursos de nós 200, 201.
[00191] O processo 700 começa no bloco 702 e inclui a execução de monitoramento de sistema de computação 100 do código de programa executado por um primeiro núcleo de processador. Em algumas implementações, o primeiro núcleo de processador é configurado para executar pelo menos uma primeira porção do código de programa que é monitorado. No bloco 704 do processo 700, o sistema 100 monitora a execução do código de programa executado por um segundo núcleo de processador. Em algumas implementações, o segundo núcleo de processador é configurado para executar pelo menos uma segunda porção do código de programa que é monitorado.
[00192] No bloco 706, o sistema 100 detecta que pelo menos uma condição de gatilho é satisfeita. Em algumas implementações, o sistema 100 detecta que a condição de gatilho é satisfeita com base na identificação de uma ocorrência de um operando em pelo menos uma porção do código de programa executado por um dentre o primeiro núcleo de processador ou o segundo núcleo de processador. Em algumas implementações, o código de programa de execução no sistema 100 inclui lógica de processamento de gatilho para acionar eventos de rastreamento.
[00193] Em alguns casos, a lógica do gatilho é associada a uma instrução “definir marca de rastreamento” que é inserida em um ou mais fluxos de instruções. A lógica de gatilho pode incluir a identificação da ocorrência de um operando de marca de rastreamento da instrução, a análise do operando de marca de rastreamento e a comparação do operando com os valores de uma janela de marca de rastreamento de exemplo. Em alguns casos, essa análise e comparação é usada para detectar que a primeira condição de gatilho é satisfeita.
[00194] Em outros casos, a lógica de gatilho está associada a um valor de tempo predefinido que pode ser inserido em um ou mais fluxos de instrução, a um usuário externo de sistema 100 ou a um compilador de exemplo do sistema. A lógica de gatilho pode incluir a determinação de que uma hora atual de pelo menos um relógio de sistema de computação indica um valor de tempo predefinido usado para iniciar um ou mais eventos de rastreamento. Em algumas implementações, determinar que a hora atual indica um valor de tempo predefinido pode incluir receber o valor de tempo predefinido e comparar o valor de tempo predefinido aos valores de tempo de uma janela de tempo predefinida de exemplo.
[00195] No bloco 708, sensível à detecção de que a condição de gatilho é satisfeita, o sistema 100 inicia pelo menos um primeiro evento de rastreamento que gera dados de rastreamento. Os dados de rastreamento gerados identificam os respectivos eventos de hardware que ocorrem em unidades de processador distribuídas que incluem pelo menos o primeiro núcleo de processador e o segundo núcleo de processador.
[00196] Por exemplo, responsivo a detectar que a condição de gatilho é satisfeita, o sistema 100 pode iniciar um evento de rastreamento sincronizado que gera dados de rastreamento identificando eventos de hardware que ocorrem no FPC 104 e no SPC 106. Em algumas implementações, os dados de rastreamento identificam um identificador de rastreamento exclusivo para os respectivos eventos de hardware. Em alguns casos, os eventos de hardware incluem vários eventos de hardware sincronizados e pelo menos dois eventos de hardware dos vários eventos sincronizados são sincronizados quando os eventos compartilham um carimbo de hora do evento de hardware global.
[00197] Em algumas implementações, várias condições de gatilho podem ser associadas ao código de programa de execução. Em alguns casos, uma condição de gatilho específica pode ser satisfeita com base na identificação de uma ocorrência de um operando específico em pelo menos uma porção do código de programa executado por pelo menos o primeiro ou segundo núcleo de processador. O operando específico pode incluir um dos vários valores de parâmetro que podem ser usados para iniciar um segundo evento de rastreamento de um ou mais eventos de rastreamento. Nesta implementação, a detecção de que a condição de gatilho específica é satisfeita pode incluir, sistema 100 detectando de que um valor de parâmetro específico excede um primeiro valor de limite de um registro.
[00198] Em algumas implementações, responsivo à detecção de que a condição de gatilho específica é satisfeita, o sistema 100 inicia um evento de rastreamento, gerando dados de rastreamento que identificam pelo menos um atributo que é compartilhado entre os respectivos eventos de hardware ocorrendo nas unidades de processador distribuídas. Em algumas implementações, um atributo dos respectivos eventos de hardware pode incluir pelo menos um endereço de memória de origem, um endereço de memória de destino ou uma etapa de computação de sequência/programa. Considerando que pelo menos um atributo compartilhado pode incluir uma etapa de sequência específica ou uma etapa de programa do código de programa.
[00199] Em algumas implementações, uma ou mais condições de gatilho podem ser associadas a pelo menos uma de: 1) uma etapa de sequência específica do código de programa; 2) um parâmetro de controle global que indica um estado de desempenho específico das unidades de processador distribuídas; 3) uma hora atual ou um parâmetro de tempo específico indicado por um relógio/contador de tempo global das unidades de processador distribuídas; ou 4) uma janela de tempo predefinida associada ao relógio de tempo global.
[00200] Em algumas implementações, o sistema 100 também pode detectar que o valor de parâmetro específico do operando específico, ou um determinado valor de tempo predefinido, excede um segundo valor de limite do registro. Em alguns casos, responsivo a esta detecção, o sistema 100 pode parar o segundo evento de rastreamento quando o valor de parâmetro específico de um determinado operando, ou um determinado valor de tempo predefinido, excede o segundo valor de limite do registro.
[00201] No bloco 710 do processo 700, o sistema 100 fornece, a um dispositivo hospedeiro, um conjunto correlacionado de dados de rastreamento que inclui os respectivos eventos de hardware. Em algumas implementações, o conjunto correlacionado de dados de rastreamento indica pelo menos uma sequência ordenada por tempo dos respectivos eventos de hardware que são gerados quando a primeira condição de gatilho é satisfeita. Para cada um dos respectivos eventos de hardware, os dados de rastreamento incluem pelo menos um carimbo de hora do evento de hardware para o evento de hardware e os metadados que caracterizam o evento de hardware. Em alguns casos, o conjunto correlacionado de dados de rastreamento corresponde, pelo menos em parte, à estrutura de dados 620.
[00202] No bloco 712, o sistema de computação 100 utiliza o conjunto correlacionado de dados de rastreamento para analisar o desempenho do código de programa executado por pelo menos o primeiro núcleo de processador e o segundo núcleo de processador. Em algumas implementações, a estrutura de dados 620 (isto é, correspondente aos dados de rastreamento correlacionados) é usada pelo sistema hospedeiro 126 para analisar o desempenho do código de programa executado por pelo menos os núcleos de processador 104 e 106. Da mesma forma, a estrutura de dados 620 pode ser usada pelo sistema hospedeiro 126 para analisar o desempenho de pelo menos um componente de sistema 100.
[00203] Por exemplo, o sistema hospedeiro 126, ou um usuário de exemplo, pode analisar a estrutura de dados 620 para detectar ou determinar se há um problema de desempenho associado à execução de um módulo de software específico do código de programa. Um exemplo de problema pode incluir a falha do módulo de software em concluir a execução de determinados fluxos de instruções dentro de uma janela de tempo de execução distribuída, ou abaixo de uma latência de limite.
[00204] Além disso, o utilizador, ou dispositivo/sistema hospedeiro 126, pode detectar ou determinar se um componente específico de sistema 100 está a funcionar acima ou abaixo de um nível de desempenho limite. Um exemplo de problema relacionado ao desempenho do componente pode incluir um determinado componente de hardware que gera dados de resultado que estão fora dos intervalos de parâmetros de resultado de limite aceitáveis. Em algumas implementações, os dados de resultados gerados podem ser inconsistentes com os dados de resultados gerados por outros componentes relacionados de sistema 100 que executam instruções/operações substancialmente semelhantes.
[00205] Por exemplo, durante a execução do código de programa, um primeiro componente de sistema 100 pode ser necessário para completar uma operação e gerar um resultado. Do mesmo modo, pode ser necessário um segundo componente de sistema 100 para completar uma operação substancialmente semelhante e para gerar um resultado substancialmente semelhante. A análise de um conjunto correlacionado de dados de rastreamento pode indicar que o segundo componente gerou um resultado consideravelmente diferente do resultado gerado pelo primeiro componente. Da mesma forma, um exemplo de estrutura de dados de entradas de rastreamento correlacionadas pode indicar valores de parâmetros de resultado do segundo componente que estão fora dos intervalos de parâmetros aceitáveis. Esses resultados podem indicar um possível problema de desempenho do segundo componente.
[00206] Modalidades da matéria e as operações funcionais descritas neste relatório descritivo podem ser implementadas em circuitos eletrônicos digitais, em software de computador ou firmware tangivelmente incorporados, em hardware de computador, incluindo as estruturas divulgadas neste relatório descritivo e seus equivalentes estruturais, ou em combinações de um ou mais deles. Modalidades da matéria descrita neste relatório descritivo podem ser implementadas como um ou mais programas de computador, isto é, um ou mais módulos de instruções de programa de computador codificados em uma portadora de programa tangencial não transitória para execução por, ou para controlar a operação de aparelho de processamento de dados. Alternativamente, ou adicionalmente, as instruções do programa podem ser codificadas em um sinal propagado gerado artificialmente, por exemplo, um sinal elétrico, óptico ou eletromagnético gerado por máquina, que é gerado para codificar informação para transmissão para um aparelho receptor adequado para execução por um aparelho de processamento de dados. O meio de armazenamento de computador pode ser um dispositivo de armazenamento legível por máquina, um substrato de armazenamento legível por máquina, um dispositivo de memória de acesso aleatório ou em série, ou uma combinação de um ou mais destes.
[00207] Os processos e fluxos lógicos descritos neste relatório descritivo podem ser realizados por um ou mais computadores programáveis executando um ou mais programas de computador para executar funções operando em dados de entrada e gerando saída(s). Os processos e fluxos lógicos também podem ser executados por, e os aparelhos também podem ser implementados como circuitos lógicos para fins especiais, por exemplo, um FPGA (matriz de portas programáveis em campo), um ASIC (circuito integrado específico de aplicação) ou um GPGPU (unidade de processamento gráfico para fins gerais).
[00208] Computadores adequados para a execução de um programa de computador incluem, a título de exemplo, podem ser baseados em microprocessadores de uso geral ou especial ou ambos, ou qualquer outro tipo de unidade central de processamento. Geralmente, uma unidade de processamento central receberá instruções e dados de uma memória somente de leitura ou de uma memória de acesso aleatório ou ambas. Os elementos essenciais de um computador são uma unidade central de processamento para realizar ou executar instruções e um ou mais dispositivos de memória para armazenar instruções e dados. Geralmente, um computador também incluirá, ou estará operativamente acoplado para receber dados ou transferir dados para, ou ambos, um ou mais dispositivos de armazenamento em massa para armazenamento de dados, por exemplo, discos magnéticos, ópticos magnetos, ou discos ópticos. No entanto, um computador não precisa ter esses dispositivos.
[00209] O meio legível por computador adequado para armazenar instruções de programa de computador e dados inclui todas as formas de memória não volátil, meio e dispositivos de memória, incluindo exemplos de dispositivos de memória semicondutores, por exemplo, EPROM, EEPROM e dispositivos de memória flash; discos magnéticos, por exemplo, discos rígidos internos ou discos removíveis. O processador e a memória podem ser complementados por, ou incorporados em circuitos lógicos de propósito especial.
[00210] Embora este relatório descritivo contenha muitos detalhes específicos de implementação, estes não devem ser interpretados como limitações no escopo de qualquer invenção ou do que possa ser reivindicado, mas sim como descrições de características que podem ser específicas para modalidades específicas de invenções específicas. Determinadas características que são descritas neste relatório descritivo no contexto de modalidades separadas podem também ser implementadas em combinação em uma única modalidade. Inversamente, várias características que são descritas no contexto de uma única modalidade podem também ser implementadas em múltiplas modalidades separadamente ou em qualquer subcombinação adequada. Além disso, embora as características possam ser descritas acima como atuando em certas combinações e até mesmo inicialmente reivindicadas como tal, uma ou mais características de uma combinação reivindicada podem em alguns casos ser removidas da combinação, e a combinação reivindicada pode ser dirigida para uma subcombinação ou variação de uma subcombinação.
[00211] Da mesma forma, enquanto as operações são representadas nos desenhos em uma ordem específica, isto não deve ser entendido como requerendo que tais operações sejam realizadas na ordem específica mostrada ou em ordem sequencial, ou que todas as operações ilustradas sejam realizadas, para alcançar resultados desejáveis. Em determinadas circunstâncias, o processamento paralelo e de várias tarefas pode ser vantajoso. Além disso, a separação de vários módulos e componentes de sistema nas modalidades descritas acima não deve ser entendida como exigindo tal separação em todas as modalidades, e deve ser entendido que os componentes e sistemas de programas descritos podem ser geralmente integrados em um único produto de software ou empacotados em vários produtos de software.
[00212] Modalidades específicas da matéria foram descritas. Outras modalidades estão dentro do escopo das seguintes reivindicações. Por exemplo, as ações citadas nas reivindicações podem ser realizadas em uma ordem diferente e ainda alcançar resultados desejáveis. Como um exemplo, os processos representados nas figuras anexas não requerem necessariamente a ordem específica mostrada, ou ordem sequencial, para alcançar os resultados desejados. Em certas implementações, o processamento paralelo e de várias tarefas pode ser vantajoso.

Claims (19)

1. Método implementado por computador executado por um sistema de coleta de evento tendo um ou mais componentes de circuito de hardware, o método compreendendo: monitorar a execução de conjunto de instruções por um primeiro processador de rede neural de múltiplos núcleos no sistema de coleta de evento, o primeiro processador de rede neural de múltiplos núcleos sendo configurado para executar uma primeira porção do conjunto de instruções para executar cálculos para cargas de trabalho de inferência de uma rede neural multicamada, em que a rede neural multicamada é implementada em um circuito de hardware; monitorar a execução do conjunto de instruções por um segundo processador de rede neural de múltiplos núcleos no sistema de coleta de evento, o segundo processador de rede neural de múltiplos núcleos sendo configurado para executar uma segunda porção do conjunto de instruções para executar os cálculos para as cargas de trabalho de inferência da rede neural multicamada; o método caracterizado por: detectar, pelo sistema de coleta de evento, que uma condição de gatilho é satisfeita por identificar uma ocorrência de um operando na primeira porção do conjunto de instruções ou na segunda porção do conjunto de instruções, em que cada porção do conjunto de instruções inclui múltiplas sequências de conjunto de instruções que representam etapas computacionais das cargas de trabalho de inferência e o operando inclui um primeiro valor de parâmetro que indica uma sequência de conjunto de instruções específica das múltiplas sequências de conjunto de instruções para iniciar eventos de rastreamento sincronizados; responsivo à detecção de que a condição de gatilho é satisfeita, iniciar, pelo sistema de coleta de evento, um primeiro evento de rastreamento sincronizado que ocorre durante uma etapa computacional específica das cargas de trabalho de inferência para gerar dados de rastreamento identificando os respectivos eventos de hardware ocorrendo nos componentes de circuito de hardware distribuídos do sistema de coleta de evento, e para cada um dos respectivos eventos de hardware, os dados de rastreamento compreendem um carimbo de hora de evento de hardware; gerar, pelo sistema de coleta de evento e utilizando os dados de rastreamento, uma estrutura de dados que correlaciona os dados de rastreamento com base na etapa computacional específica das cargas de trabalho de inferência; transmitir, para um controlador de hospedeiro e utilizando um bloco de interface de hospedeiro do sistema de coleta de evento, a estrutura de dados que inclui os dados de rastreamento correlacionados com base na etapa computacional específica das cargas de trabalho de inferência; determinar, pelo controlador de hospedeiro, um ou mais atributos de desempenho com base nos respectivos eventos de hardware que foram identificados pelos dados de rastreamento na estrutura de dados recebida utilizando o bloco de interface de hospedeiro; e utilizar, pelo controlador de hospedeiro, um ou mais atributos de desempenho para analisar a execução do conjunto de instruções pelo primeiro e segundo processadores de rede neural de múltiplos núcleos quando a etapa computacional específica é executada no primeiro e segundo processadores de rede neural de múltiplos núcleos em diferentes tempos respectivos.
2. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que o primeiro evento de rastreamento sincronizado gera dados de rastreamento indicando um identificador de rastreamento exclusivo para os respectivos eventos de hardware, e em que os eventos de hardware incluem uma pluralidade de eventos de hardware sincronizados, e dois eventos de hardware são sincronizados quando os eventos são associados com a mesma etapa computacional das cargas de trabalho de inferência.
3. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que detectar que a condição de gatilho é satisfeita compreende: detectar, pelo sistema de coleta de evento, que um dentre: i) o primeiro valor de parâmetro do operando excede um primeiro valor de limite de um registro, ou ii) uma hora atual indicada por um relógio do sistema de coleta de evento excede um primeiro valor de limite de um registro; e responsivo a detectar que a condição de gatilho é satisfeita, iniciar, pelo sistema de coleta de evento, um segundo evento de rastreamento sincronizado que gera dados de rastreamento, em que os dados de rastreamento identificam pelo menos um atributo que é compartilhado entre os respectivos eventos de hardware que ocorrem no sistema de coleta de evento.
4. Método, de acordo com a reivindicação 3, caracterizado pelo fato de que compreende ainda: detectar, pelo sistema de coleta de evento, que um dentre: um segundo valor de parâmetro do operando excede um segundo valor de limite do registro, ou a hora atual indicada pelo relógio do sistema de coleta de evento excede um segundo valor de limite do registro; e responsivo a detectar, parar, pelo sistema de coleta de evento, o segundo evento de rastreamento sincronizado quando o segundo valor de parâmetro do operando exceder o segundo valor de limite, ou quando um segundo valor de tempo predefinido exceder o segundo valor de limite.
5. Método, de acordo com a reivindicação 3, caracterizado pelo fato de que: o operando inclui ainda: um parâmetro de controle global que indica um estado de desempenho específico do sistema de coleta de evento; e o primeiro valor de limite do registro inclui pelo menos um dentre: um valor de tempo predefinido indicado por um relógio de tempo global do sistema de coleta de evento; ou um valor de tempo específico de uma janela de tempo predefinida associada ao relógio de tempo global.
6. Método, de acordo com a reivindicação 3, caracterizado pelo fato de que: o operando tem uma primeira estrutura de dados binários e o primeiro valor de parâmetro do operando corresponde a uma marca de rastreamento, o primeiro valor de limite do registro tem uma segunda estrutura de dados binários e a hora atual é indicada por um relógio de tempo global, e em que o relógio de tempo global é utilizado pelo sistema de coleta de evento para gerar um ou mais carimbos de hora de evento de hardware.
7. Método, de acordo com a reivindicação 3, caracterizado pelo fato de que compreende ainda: inserir, por um compilador do sistema de coleta de evento, o operando da condição de gatilho na primeira porção do conjunto de instruções executado pelo primeiro processador de rede neural de múltiplos núcleos; e inserir, pelo compilador do sistema de coleta de evento, um valor de tempo predefinido da condição de gatilho na segunda porção do conjunto de instruções executado pelo segundo processador de rede neural de múltiplos núcleos.
8. Método, de acordo com a reivindicação 3, caracterizado pelo fato de que iniciar pelo menos um do primeiro evento de rastreamento sincronizado ou do segundo evento de rastreamento sincronizado, compreende: gerar, pelo sistema de coleta de evento, um primeiro sinal de controle recebido por um primeiro registro de contagem do primeiro processador de rede neural de múltiplos núcleos, o primeiro sinal de controle fazendo com que os dados para um primeiro evento de hardware sejam armazenados no primeiro registro de contagem; e gerar, pelo sistema de coleta de evento, um segundo sinal de controle recebido por um segundo registro de contagem do segundo processador de rede neural de múltiplos núcleos, o segundo sinal de controle fazendo com que os dados para um segundo evento de hardware sejam armazenados no segundo registro de contagem.
9. Método, de acordo com a reivindicação 8, caracterizado pelo fato de que os dados para um do primeiro evento de hardware ou do segundo evento de hardware, compreendem pelo menos um dentre: um número de bytes gravados para um buffer de memória específico de um processador de rede neural de múltiplos núcleos específico do sistema de coleta de evento; ou um número de instruções executadas por um processador de rede neural de múltiplos núcleos específico do sistema de coleta de evento.
10. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que compreende ainda: identificar, pelo sistema de coleta de evento, uma ocorrência de um segundo operando na porção do conjunto de instruções executado pelo primeiro ou segundo processadores de rede neural de múltiplos núcleos, o segundo operando incluindo um segundo valor de parâmetro; determinar, pelo sistema de coleta de evento, que uma condição de filtro é satisfeita com base no segundo valor de parâmetro do segundo operando exceder um valor de limite específico de um registro ou estar abaixo de um valor de limite específico do registro; e responsivo a determinar que a condição de filtro é satisfeita, filtrar, pelo sistema de coleta de evento, um ou mais eventos de rastreamento, em que filtrar um ou mais eventos de rastreamento compreende impedir o armazenamento de dados de rastreamento para um ou mais eventos de hardware.
11. Método, de acordo com a reivindicação 8, caracterizado pelo fato de que cada um de o primeiro registro de contagem e o segundo registro de contagem é um de múltiplos contadores de desempenho configurados para armazenar dados de contagem sobre o desempenho das cargas de trabalho de inferência por processadores de rede neural de múltiplos núcleos do sistema de coleta de evento, e em que pelo menos um contador de desempenho inclui um dentre: um contador de atividade, um contador de paralisação, um contador estatístico, ou um contador de amostragem.
12. Método, de acordo com a reivindicação 11, caracterizado pelo fato de que o um ou mais parâmetros de contagem dos dados de contagem indicam pelo menos um dentre: i) um número de instruções recebidas por um processador de rede neural de múltiplos núcleos específico; ii) um número de instruções processadas pelo processador de rede neural de múltiplos núcleos específico; iii) um número de instruções executadas pelo processador de rede neural de múltiplos núcleos específico; ou iv) um número de leituras de memória e um número de gravações de memória executadas pelo processador de rede neural de múltiplos núcleos específico.
13. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que um atributo de desempenho que é utilizado para analisar o conjunto de instruções de execução compreende pelo menos um dentre: i) uma frequência de paralisação de um processador de rede neural de múltiplos núcleos específico que executa o conjunto de instruções; ii) uma indicação de que a utilização do processador de rede neural de múltiplos núcleos específico está abaixo de um limite de utilização; ou iii) uma indicação de que uma fila de armazenamento de dados usada pelo processador de rede neural de múltiplos núcleos específico está em, ou abaixo de, um limite de ocupação de fila.
14. Sistema de coleta de evento de hardware, compreendendo: um ou mais componentes de processador, incluindo um ou mais núcleos de processador; uma ou mais unidades de armazenamento legíveis por máquina armazenando instruções que são executáveis por um ou mais componentes de processador para causar desempenho de operações compreendendo: monitorar a execução de conjunto de instruções por um primeiro processador de rede neural de múltiplos núcleos no sistema de coleta de evento, o primeiro processador de rede neural de múltiplos núcleos sendo configurado para executar uma primeira porção do conjunto de instruções para executar cálculos para cargas de trabalho de inferência de uma rede neural multicamada, em que a rede neural multicamada é implementada em um circuito de hardware; monitorar a execução do conjunto de instruções por um segundo processador de rede neural de múltiplos núcleos no sistema de coleta de evento, o segundo processador de rede neural de múltiplos núcleos sendo configurado para executar uma segunda porção do conjunto de instruções para executar os cálculos para as cargas de trabalho de inferência da rede neural multicamada; o sistema de coleta de evento de hardware caracterizado por: detectar, pelo sistema de coleta de evento, que uma condição de gatilho é satisfeita por identificar uma ocorrência de um operando na primeira porção do conjunto de instruções ou na segunda porção do conjunto de instruções, em que cada porção do conjunto de instruções inclui múltiplas sequências de conjunto de instruções que representam etapas computacionais das cargas de trabalho de inferência e o operando inclui um primeiro valor de parâmetro que indica uma sequência de conjunto de instruções específica das múltiplas sequências de conjunto de instruções para iniciar eventos de rastreamento sincronizados; responsivo à detecção de que a condição de gatilho é satisfeita, iniciar, pelo sistema de coleta de evento, um primeiro evento de rastreamento sincronizado que ocorre durante uma etapa computacional específica das cargas de trabalho de inferência para gerar dados de rastreamento identificando os respectivos eventos de hardware ocorrendo nos componentes de circuito de hardware distribuídos do sistema de coleta de evento, e para cada um dos respectivos eventos de hardware, os dados de rastreamento compreendem um carimbo de hora de evento de hardware; gerar, pelo sistema de coleta de evento e utilizando os dados de rastreamento, uma estrutura de dados que correlaciona os dados de rastreamento com base na etapa computacional específica das cargas de trabalho de inferência; transmitir, para um controlador de hospedeiro e utilizando um bloco de interface de hospedeiro do sistema de coleta de evento, a estrutura de dados que inclui os dados de rastreamento correlacionados com base na etapa computacional específica das cargas de trabalho de inferência; determinar, pelo controlador de hospedeiro, um ou mais atributos de desempenho com base nos respectivos eventos de hardware que foram identificados pelos dados de rastreamento na estrutura de dados recebida utilizando o bloco de interface de hospedeiro; e utilizar, pelo controlador de hospedeiro, um ou mais atributos de desempenho para analisar a execução do conjunto de instruções pelo primeiro e segundo processadores de rede neural de múltiplos núcleos quando a etapa computacional específica é executada no primeiro e segundo processadores de rede neural de múltiplos núcleos em diferentes tempos respectivos.
15. Sistema de coleta de evento de hardware, de acordo com a reivindicação 14, caracterizado pelo fato de que o primeiro evento de rastreamento sincronizado gera dados de rastreamento indicando um identificador de rastreamento exclusivo para os respectivos eventos de hardware, e em que os eventos de hardware incluem uma pluralidade de eventos de hardware sincronizados, e dois eventos de hardware são sincronizados quando os eventos são associados com a mesma etapa computacional das cargas de trabalho de inferência.
16. Sistema de coleta de evento de hardware, de acordo com a reivindicação 14, caracterizado pelo fato de que detectar que a condição de gatilho é satisfeita compreende: detectar, pelo sistema de coleta de evento, que um dentre: i) o primeiro valor de parâmetro do operando excede um primeiro valor de limite de um registro, ou ii) uma hora atual indicada por um relógio do sistema de coleta de evento excede um primeiro valor de limite de um registro; e responsivo a detectar que a condição de gatilho é satisfeita, iniciar, pelo sistema de coleta de evento, um segundo evento de rastreamento sincronizado que gera dados de rastreamento, em que os dados de rastreamento identificam pelo menos um atributo que é compartilhado entre os respectivos eventos de hardware que ocorrem no sistema de coleta de evento.
17. Sistema de coleta de evento de hardware, de acordo com a reivindicação 16, caracterizado pelo fato de que as operações compreendem ainda: detectar, pelo sistema de coleta de evento, que um dentre: um segundo valor de parâmetro do operando excede um segundo valor de limite do registro, ou a hora atual indicada pelo relógio do sistema de coleta de evento excede um segundo valor de limite do registro; e responsivo a detectar, parar, pelo sistema de coleta de evento, o segundo evento de rastreamento sincronizado quando o segundo valor de parâmetro do operando exceder o segundo valor de limite, ou quando um segundo valor de tempo predefinido exceder o segundo valor de limite.
18. Sistema de coleta de evento de hardware, de acordo com a reivindicação 16, caracterizado pelo fato de que: o operando inclui ainda: um parâmetro de controle global que indica um estado de desempenho específico do sistema de coleta de evento; e o primeiro valor de limite do registro inclui pelo menos um dentre: um valor de tempo predefinido indicado por um relógio de tempo global do sistema de coleta de evento; ou um valor de tempo específico de uma janela de tempo predefinida associada ao relógio de tempo global.
19. Sistema de coleta de evento de hardware, de acordo com a reivindicação 16, caracterizado pelo fato de que: o operando tem uma primeira estrutura de dados binários e o primeiro valor de parâmetro do operando corresponde a uma marca de rastreamento, o valor de limite do registro tem uma segunda estrutura de dados binários e a hora atual é indicada por um relógio de tempo global, e em que o relógio de tempo global é utilizado pelo sistema de coleta de evento para gerar um ou mais carimbos de hora de evento de hardware.
BR112019015427-2A 2017-03-29 2017-10-20 Coleta de evento de hardware síncrono BR112019015427B1 (pt)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US15/472,932 US10365987B2 (en) 2017-03-29 2017-03-29 Synchronous hardware event collection
US15/472,932 2017-03-29
PCT/US2017/057638 WO2018182783A1 (en) 2017-03-29 2017-10-20 Synchronous hardware event collection

Publications (2)

Publication Number Publication Date
BR112019015427A2 BR112019015427A2 (pt) 2020-03-31
BR112019015427B1 true BR112019015427B1 (pt) 2022-01-11

Family

ID=60201424

Family Applications (1)

Application Number Title Priority Date Filing Date
BR112019015427-2A BR112019015427B1 (pt) 2017-03-29 2017-10-20 Coleta de evento de hardware síncrono

Country Status (12)

Country Link
US (3) US10365987B2 (pt)
EP (1) EP3382552A1 (pt)
JP (3) JP7196083B2 (pt)
KR (3) KR102493495B1 (pt)
CN (2) CN108694109B (pt)
BR (1) BR112019015427B1 (pt)
DE (2) DE202017106508U1 (pt)
GB (1) GB2561043B (pt)
HK (1) HK1259155A1 (pt)
SG (1) SG11201906749UA (pt)
TW (3) TWI681332B (pt)
WO (1) WO2018182783A1 (pt)

Families Citing this family (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10972333B2 (en) * 2016-03-16 2021-04-06 Telefonaktiebolaget Lm Ericsson (Publ) Method and device for real-time network event processing
US9875167B1 (en) 2017-03-29 2018-01-23 Google Inc. Distributed hardware tracing
US10365987B2 (en) 2017-03-29 2019-07-30 Google Llc Synchronous hardware event collection
US11144087B2 (en) * 2018-08-10 2021-10-12 Nvidia Corporation Efficient performance monitoring of integrated circuit(s) having distributed clocks
CN109981349B (zh) * 2019-02-27 2022-02-25 华为云计算技术有限公司 调用链信息查询方法以及设备
CN110046116B (zh) * 2019-04-23 2020-08-21 上海燧原智能科技有限公司 一种张量填充方法、装置、设备及存储介质
CN110311863B (zh) * 2019-05-09 2020-08-21 北京邮电大学 一种路由路径确定方法及装置
US11294750B2 (en) * 2019-07-15 2022-04-05 Micron Technology, Inc. Media management logger for a memory sub-system
KR20220041926A (ko) * 2019-08-16 2022-04-01 구글 엘엘씨 온-칩 연산의 명시적 스케줄링
US11630919B1 (en) * 2019-09-30 2023-04-18 Amazon Technologies, Inc. Management of sensitive data using static code analysis
CN111160558B (zh) * 2019-12-13 2023-04-28 合肥本源量子计算科技有限责任公司 量子芯片控制器、量子计算处理系统和电子设备
EP3839740A1 (en) * 2019-12-20 2021-06-23 GrAl Matter Labs S.A.S. Message-based processing system and method of operating the same
WO2021173872A1 (en) * 2020-02-27 2021-09-02 Siemens Healthcare Diagnostics Inc. Automatic sensor trace validation using machine learning
US11100166B1 (en) 2020-12-21 2021-08-24 Coupang Corp. Systems and methods for automatically updating guaranteed computing counters
US20220198110A1 (en) * 2020-12-23 2022-06-23 Intel Corporation Debugging architecture for system in package composed of multiple semiconductor chips
KR20230157503A (ko) * 2021-03-31 2023-11-16 후아웨이 테크놀러지 컴퍼니 리미티드 동기화 방법 및 장치
KR102648657B1 (ko) * 2021-10-06 2024-03-15 에스케이텔레콤 주식회사 무선통신시스템에서 원거리 통신을 위한 통신 장치 및 이를 위한 방법
US11966745B2 (en) 2021-11-15 2024-04-23 Google Llc Sparse SIMD cross-lane processing unit
US11972263B2 (en) 2021-11-22 2024-04-30 Google Llc Cooperative instruction prefetch on multicore system
WO2023128009A1 (ko) * 2021-12-30 2023-07-06 리벨리온 주식회사 뉴럴 프로세싱 장치 및 그의 동기화 방법
US11977499B2 (en) * 2022-03-22 2024-05-07 Google Llc Streaming transfers and ordering model
US11899516B1 (en) 2023-07-13 2024-02-13 T-Mobile Usa, Inc. Creation of a digital twin for auto-discovery of hierarchy in power monitoring

Family Cites Families (89)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4598364A (en) 1983-06-29 1986-07-01 International Business Machines Corporation Efficient trace method adaptable to multiprocessors
JPH0283749A (ja) 1988-09-21 1990-03-23 Hitachi Ltd マイクロプロセッサの内部割込み制御方式
JPH04148439A (ja) 1990-10-12 1992-05-21 Nec Corp 情報処理装置のトレース方式
JPH04242455A (ja) 1991-01-16 1992-08-31 Nec Ibaraki Ltd プロセッサ間通信トレース回路
JPH05128079A (ja) 1991-10-31 1993-05-25 Nec Corp マルチプロセツサシステムにおけるトレース方式
JPH07200352A (ja) 1993-12-28 1995-08-04 Hitachi Ltd データプロセッサ、プログラム翻訳方法、及びデバッグツール
US6128415A (en) 1996-09-06 2000-10-03 Polaroid Corporation Device profiles for use in a digital image processing system
US5682328A (en) 1996-09-11 1997-10-28 Bbn Corporation Centralized computer event data logging system
US5796939A (en) * 1997-03-10 1998-08-18 Digital Equipment Corporation High frequency sampling of processor performance counters
US6189140B1 (en) 1997-04-08 2001-02-13 Advanced Micro Devices, Inc. Debug interface including logic generating handshake signals between a processor, an input/output port, and a trace logic
US6256775B1 (en) 1997-12-11 2001-07-03 International Business Machines Corporation Facilities for detailed software performance analysis in a multithreaded processor
US6233531B1 (en) 1997-12-19 2001-05-15 Advanced Micro Devices, Inc. Apparatus and method for monitoring the performance of a microprocessor
US6098169A (en) 1997-12-23 2000-08-01 Intel Corporation Thread performance analysis by monitoring processor performance event registers at thread switch
US6134676A (en) 1998-04-30 2000-10-17 International Business Machines Corporation Programmable hardware event monitoring method
EP0992907B1 (en) * 1998-10-06 2005-09-28 Texas Instruments Inc. Trace fifo management
US6353924B1 (en) * 1999-02-08 2002-03-05 Incert Software Corporation Method for back tracing program execution
JP2000348007A (ja) * 1999-06-03 2000-12-15 Nec Corp マルチプロセッサシステムのための動作トレース時刻同期方式およびその方法
US6530076B1 (en) 1999-12-23 2003-03-04 Bull Hn Information Systems Inc. Data processing system processor dynamic selection of internal signal tracing
US6868376B2 (en) * 2000-03-02 2005-03-15 Texas Instruments Incorporated Debug bi-phase export and data recovery
US6789182B1 (en) 2000-11-13 2004-09-07 Kevin Jay Brothers System and method for logging computer event data and physical components of a complex distributed system
US6813731B2 (en) 2001-02-26 2004-11-02 Emc Corporation Methods and apparatus for accessing trace data
US6769054B1 (en) 2001-02-26 2004-07-27 Emc Corporation System and method for preparation of workload data for replaying in a data storage environment
US6988155B2 (en) 2001-10-01 2006-01-17 International Business Machines Corporation Aggregation of hardware events in multi-node systems
US7080283B1 (en) 2002-10-15 2006-07-18 Tensilica, Inc. Simultaneous real-time trace and debug for multiple processing core systems on a chip
US7069176B2 (en) 2003-08-07 2006-06-27 Arm Limited Trace source correlation in a data processing apparatus
JP2005165825A (ja) * 2003-12-04 2005-06-23 Canon Inc トレース情報記録装置
US7529979B2 (en) 2003-12-12 2009-05-05 International Business Machines Corporation Hardware/software based indirect time stamping methodology for proactive hardware/software event detection and control
US20060005083A1 (en) 2004-06-30 2006-01-05 International Business Machines Corporation Performance count tracing
US9038070B2 (en) 2004-09-14 2015-05-19 Synopsys, Inc. Debug in a multicore architecture
GB0420442D0 (en) 2004-09-14 2004-10-20 Ignios Ltd Debug in a multicore architecture
US7543161B2 (en) 2004-09-30 2009-06-02 International Business Machines Corporation Method and apparatus for tracking variable speed microprocessor performance caused by power management in a logically partitioned data processing system
US7673050B2 (en) 2004-12-17 2010-03-02 Microsoft Corporation System and method for optimizing server resources while providing interaction with documents accessible through the server
US7418629B2 (en) 2005-02-11 2008-08-26 International Business Machines Corporation Synchronizing triggering of multiple hardware trace facilities using an existing system bus
JP2006318412A (ja) 2005-05-16 2006-11-24 Toshiba Corp 半導体装置
US8079037B2 (en) * 2005-10-11 2011-12-13 Knoa Software, Inc. Generic, multi-instance method and GUI detection system for tracking and monitoring computer applications
JP2008234191A (ja) 2007-03-19 2008-10-02 Toshiba Corp ハードウエアモニタ管理装置及びハードウエアモニタ機能の実行方法
US8762951B1 (en) 2007-03-21 2014-06-24 Oracle America, Inc. Apparatus and method for profiling system events in a fine grain multi-threaded multi-core processor
US8181185B2 (en) * 2007-05-31 2012-05-15 Intel Corporation Filtering of performance monitoring information
US20110246521A1 (en) * 2007-08-06 2011-10-06 Hui Luo System and method for discovering image quality information related to diagnostic imaging performance
JP4658182B2 (ja) 2007-11-28 2011-03-23 株式会社荏原製作所 研磨パッドのプロファイル測定方法
US20100083237A1 (en) 2008-09-26 2010-04-01 Arm Limited Reducing trace overheads by modifying trace operations
US8301759B2 (en) 2008-10-24 2012-10-30 Microsoft Corporation Monitoring agent programs in a distributed computing platform
JPWO2010097875A1 (ja) 2009-02-24 2012-08-30 パナソニック株式会社 データ処理装置、方法
JP5326708B2 (ja) 2009-03-18 2013-10-30 富士通株式会社 演算処理装置および演算処理装置の制御方法
US8572581B2 (en) 2009-03-26 2013-10-29 Microsoft Corporation Measurement and reporting of performance event rates
JP5266385B2 (ja) 2009-06-10 2013-08-21 パナソニック株式会社 トレース処理装置およびトレース処理システム
US8554892B2 (en) 2009-06-22 2013-10-08 Citrix Systems, Inc. Systems and methods for n-core statistics aggregation
US8407528B2 (en) * 2009-06-30 2013-03-26 Texas Instruments Incorporated Circuits, systems, apparatus and processes for monitoring activity in multi-processing systems
JP2011013867A (ja) * 2009-06-30 2011-01-20 Panasonic Corp データ処理装置、性能評価解析システム
US20110047358A1 (en) * 2009-08-19 2011-02-24 International Business Machines Corporation In-Data Path Tracking of Floating Point Exceptions and Store-Based Exception Indication
US8495604B2 (en) * 2009-12-30 2013-07-23 International Business Machines Corporation Dynamically distribute a multi-dimensional work set across a multi-core system
GB2478328B (en) 2010-03-03 2015-07-01 Advanced Risc Mach Ltd Method, apparatus and trace module for generating timestamps
JP2011243110A (ja) 2010-05-20 2011-12-01 Renesas Electronics Corp 情報処理装置
US8607202B2 (en) 2010-06-04 2013-12-10 Lsi Corporation Real-time profiling in a multi-core architecture
GB2481385B (en) 2010-06-21 2018-08-15 Advanced Risc Mach Ltd Tracing speculatively executed instructions
US20120042212A1 (en) 2010-08-10 2012-02-16 Gilbert Laurenti Mixed Mode Processor Tracing
US20120179898A1 (en) 2011-01-10 2012-07-12 Apple Inc. System and method for enforcing software security through cpu statistics gathered using hardware features
US8706937B2 (en) 2011-03-02 2014-04-22 Texas Instruments Incorporated Method and system of debugging multicore bus transaction problems
US8943248B2 (en) 2011-03-02 2015-01-27 Texas Instruments Incorporated Method and system for handling discarded and merged events when monitoring a system bus
US20120226839A1 (en) 2011-03-02 2012-09-06 Texas Instruments Incorporated Method and System for Monitoring and Debugging Access to a Bus Slave Using One or More Throughput Counters
US10642709B2 (en) 2011-04-19 2020-05-05 Microsoft Technology Licensing, Llc Processor cache tracing
US8683268B2 (en) 2011-06-20 2014-03-25 International Business Machines Corporation Key based cluster log coalescing
US8713370B2 (en) * 2011-08-11 2014-04-29 Apple Inc. Non-intrusive processor tracing
US8935574B2 (en) * 2011-12-16 2015-01-13 Advanced Micro Devices, Inc. Correlating traces in a computing system
US9454462B2 (en) 2012-03-16 2016-09-27 International Business Machines Corporation Run-time instrumentation monitoring for processor characteristic changes
US9237082B2 (en) 2012-03-26 2016-01-12 Hewlett Packard Enterprise Development Lp Packet descriptor trace indicators
US9021311B2 (en) 2012-08-28 2015-04-28 Freescale Semiconductor, Inc. Method and apparatus for filtering trace information
US9645870B2 (en) 2013-06-27 2017-05-09 Atmel Corporation System for debugging DMA system data transfer
US20160117196A1 (en) 2013-07-31 2016-04-28 Hewlett-Packard Development Company, L.P. Log analysis
JP6122749B2 (ja) 2013-09-30 2017-04-26 ルネサスエレクトロニクス株式会社 コンピュータシステム
TWI514145B (zh) 2013-10-21 2015-12-21 Univ Nat Sun Yat Sen 可儲存除錯資料的處理器、其快取及控制方法
US9684583B2 (en) 2013-11-05 2017-06-20 Texas Instruments Incorporated Trace data export to remote memory using memory mapped write transactions
JP2015114675A (ja) * 2013-12-09 2015-06-22 三菱電機株式会社 アプリケーションソフトウェア加速試験装置および試験方法
JP6258159B2 (ja) * 2014-08-26 2018-01-10 株式会社東芝 プログラム情報生成システム、方法、及びプログラム
US20160070636A1 (en) 2014-09-04 2016-03-10 Home Box Office, Inc. Conditional wrapper for program object
EP3035249B1 (en) 2014-12-19 2019-11-27 Intel Corporation Method and apparatus for distributed and cooperative computation in artificial neural networks
CN106033385A (zh) 2015-03-19 2016-10-19 启碁科技股份有限公司 用于追踪程序执行状态的方法与多核心处理系统
US11232848B2 (en) 2015-04-30 2022-01-25 Hewlett Packard Enterprise Development Lp Memory module error tracking
US20160378636A1 (en) 2015-06-26 2016-12-29 Intel Corporation Software-Initiated Trace Integrated with Hardware Trace
CN105354136B (zh) 2015-09-25 2018-06-15 华为技术有限公司 一种调试方法、多核处理器和调试设备
US9858167B2 (en) 2015-12-17 2018-01-02 Intel Corporation Monitoring the operation of a processor
US20170371761A1 (en) 2016-06-24 2017-12-28 Advanced Micro Devices, Inc. Real-time performance tracking using dynamic compilation
US9965375B2 (en) 2016-06-28 2018-05-08 Intel Corporation Virtualizing precise event based sampling
US9959498B1 (en) * 2016-10-27 2018-05-01 Google Llc Neural network instruction set architecture
US10175980B2 (en) * 2016-10-27 2019-01-08 Google Llc Neural network compute tile
US10127283B2 (en) 2016-10-31 2018-11-13 International Business Machines Corporation Projecting effect of in-flight streamed data on a relational database
US10365987B2 (en) 2017-03-29 2019-07-30 Google Llc Synchronous hardware event collection
US9875167B1 (en) 2017-03-29 2018-01-23 Google Inc. Distributed hardware tracing
KR101988558B1 (ko) 2017-06-07 2019-06-12 현대오트론 주식회사 멀티 코어를 갖는 마이크로콘트롤러 유닛을 감시하는 감시장치 및 그것의 동작 방법

Also Published As

Publication number Publication date
TWI808280B (zh) 2023-07-11
TW202403538A (zh) 2024-01-16
CN108694109B (zh) 2022-07-22
JP2024050667A (ja) 2024-04-10
EP3382552A1 (en) 2018-10-03
SG11201906749UA (en) 2019-08-27
JP7196083B2 (ja) 2022-12-26
GB2561043A (en) 2018-10-03
HK1259155A1 (zh) 2019-11-29
US11921611B2 (en) 2024-03-05
GB2561043B (en) 2021-01-13
KR102584961B1 (ko) 2023-10-04
JP7427759B2 (ja) 2024-02-05
JP2023036719A (ja) 2023-03-14
TW201837699A (zh) 2018-10-16
CN115168147A (zh) 2022-10-11
US20220129364A1 (en) 2022-04-28
US20180285233A1 (en) 2018-10-04
JP2020512613A (ja) 2020-04-23
KR102295511B1 (ko) 2021-08-27
KR20230017927A (ko) 2023-02-06
CN108694109A (zh) 2018-10-23
US11232012B2 (en) 2022-01-25
TW202011177A (zh) 2020-03-16
GB201717925D0 (en) 2017-12-13
KR102493495B1 (ko) 2023-01-27
WO2018182783A1 (en) 2018-10-04
US10365987B2 (en) 2019-07-30
BR112019015427A2 (pt) 2020-03-31
TWI681332B (zh) 2020-01-01
KR20210107174A (ko) 2021-08-31
KR20190096427A (ko) 2019-08-19
US20200019483A1 (en) 2020-01-16
DE202017106508U1 (de) 2018-02-05
DE102017125180A1 (de) 2018-10-04

Similar Documents

Publication Publication Date Title
BR112019015427B1 (pt) Coleta de evento de hardware síncrono
TWI661306B (zh) 用於分散式硬體追蹤之電腦實施方法、系統及非暫時性電腦儲存單元

Legal Events

Date Code Title Description
B07A Application suspended after technical examination (opinion) [chapter 7.1 patent gazette]
B06A Patent application procedure suspended [chapter 6.1 patent gazette]
B350 Update of information on the portal [chapter 15.35 patent gazette]
B09A Decision: intention to grant [chapter 9.1 patent gazette]
B16A Patent or certificate of addition of invention granted [chapter 16.1 patent gazette]

Free format text: PRAZO DE VALIDADE: 20 (VINTE) ANOS CONTADOS A PARTIR DE 20/10/2017, OBSERVADAS AS CONDICOES LEGAIS.