1. Introdução
Aplicações em tempo real, como realidade virtual (VR), jogos online, drones controlados remotamente e carros autônomos, estão se tornando cada vez mais populares. Essas aplicações em tempo real requerem baixa latência na ordem de milissegundos (ms) a microssegundos (μs) [1]-[4]. Devido a esses altos requisitos de tempo real, cada aplicativo é frequentemente instalado e executado no mesmo dispositivo terminal. No entanto, não é desejável processar cargas de trabalho pesadas no dispositivo terminal devido aos requisitos de tamanho menor e maior duração da bateria. Para atender a esses requisitos, o Instituto Europeu de Padrões de Telecomunicações (ETSI) propôs a computação de borda multiacesso (MEC) [5], que permite que um dispositivo terminal transfira essas cargas de trabalho para uma nuvem de borda localizada próxima ao dispositivo terminal. Do ponto de vista das despesas de capital e da facilidade de operação, essas nuvens de borda são frequentemente implementadas por servidores de uso geral e usam servidores virtuais, como máquinas virtuais (VMs) e contêineres. Entretanto, o encaminhamento de pacotes de uma placa de interface de rede (NIC) para uma aplicação em um servidor virtual em um servidor de uso geral traz problemas de desempenho de maior latência e menor rendimento devido à sobrecarga de virtualização [6]-[9]. Na verdade, de acordo com nossos resultados experimentais, os atrasos no encaminhamento de pacotes em uma VM podem facilmente exceder 1 ms [10]. Assim, os atrasos no encaminhamento de pacotes em um servidor virtual precisam ser reduzidos pelo menos à ordem de μs.
O consumo de energia dos servidores edge cloud também precisa ser considerado. Para obter baixa latência, são necessários ajustes de desempenho dos servidores, como fixar a frequência da unidade central de processamento (CPU) no máximo e desabilitar a função ociosa de uma CPU (C-state) [10], [11]. Esses ajustes reduzem a latência ao custo de um maior consumo de energia do servidor. Existe uma compensação entre baixa latência e economia de energia. Mesmo que o aumento no consumo de energia por servidor pareça pequeno, como alguns watts, o resultado será um enorme aumento no consumo de energia, dado o grande número de servidores. Assim, o consumo de energia do servidor deve ser o mais baixo possível.
Ao projetar uma solução de rede de baixa latência para um servidor virtual, quatro requisitos devem ser considerados. (A): Baixa latência na ordem de μs para encaminhamento de pacotes em um servidor virtual. (B): Menor consumo de energia do que as soluções existentes. (C): Não há necessidade de modificação do aplicativo. Do ponto de vista de um desenvolvedor de aplicativos, é desejável que os desenvolvedores de aplicativos usem uma solução de rede de baixa latência sem modificação do aplicativo. Os desenvolvedores de aplicativos podem facilmente usar funções de rede por meio da interface de programa de aplicativo (API) de soquetes POSIX [12], uma vez que o kernel do Linux fornece uma pilha de protocolos que inclui protocolo de internet (IP), protocolo de datagrama de usuário (UDP) e outros protocolos populares. Se uma solução de rede de baixa latência exigir funções de rede especiais, os desenvolvedores de aplicativos precisarão adquirir conhecimentos complexos sobre redes, e isso aumentará o custo do desenvolvimento de aplicativos. (D): Não há necessidade de redesenvolvimento de software para cada atualização de segurança do kernel. Como as atualizações de segurança do kernel ocorrem com frequência, o custo de redesenvolvimento de software para cada atualização de segurança do kernel seria enorme. Do ponto de vista de um provedor de serviços, é desejável que os provedores de serviços apliquem atualizações de segurança do kernel sem desenvolver novamente o software de uma solução de rede de baixa latência.
Assim, projetamos e implementamos um sistema de rede de baixa latência e eficiência energética, kernel ocupado com eficiência energética (EE-KBP), que atende aos requisitos (A), (B), (C) e (D). Este EE-KBP possui threads de pesquisa que verificam constantemente os pacotes que chegam em um kernel e os transferem imediatamente para uma pilha de protocolo de rede do kernel para atender ao requisito (A). Isto é o mesmo que KBP [10]. O sistema base, KBP, não pode atender ao requisito (B), pois os threads de polling verificam constantemente a chegada dos pacotes, independentemente de os pacotes chegarem ou não, e isso consome mais energia. Assim, o EE-KBP estende o KBP para obter menor consumo de energia, controlando a suspensão dos threads de pesquisa. A suspensão de threads de pesquisa é um desafio, pois a sobrecarga da recuperação do sono aumenta os atrasos finais do encaminhamento de pacotes. O EE-KBP minimiza esse efeito negativo ao ativar o thread de pesquisa adormecido quando uma solicitação de interrupção de hardware (hardIRQ) é acionada pela chegada de um pacote. Além disso, para aumentar o efeito de economia de energia ao colocar os threads de pesquisa em suspensão, o EE-KBP controla dinamicamente a frequência da CPU dos núcleos da CPU usados pelos threads de pesquisa. Estas extensões permitem que os requisitos (A) e (B) sejam atendidos simultaneamente. Como o EE-KBP usa uma pilha de protocolos do kernel existente e não a altera, os aplicativos podem usar a API de soquetes POSIX, e isso atende ao requisito (C). Além disso, como as alterações causadas por essas extensões são pequenas, elas podem ser aplicadas ao kernel existente por uma estrutura livepatch do kernel [13], e isso atende ao requisito (D).
O restante deste trabalho está organizado da seguinte forma:
- Análise de como combinar baixa latência e economia de energia: analisamos métodos de encaminhamento de pacotes que alcançam simultaneamente baixa latência e economia de energia (ver Seção 3);
- Projeto e implementação de EE-KBP: projetamos e implementamos um sistema de rede de baixa latência e eficiência energética (ver Seção 4);
- Demonstração dos benefícios do EE-KBP: nossos resultados experimentais indicam que o EE-KBP pode melhorar a eficiência energética, reduzir o atraso no encaminhamento de pacotes na escala μs e alcançar alto rendimento em uma configuração VM (ver Seção 5).
2. Trabalho Relacionado
O kernel do Linux usa um método de recebimento de pacotes em modo de interrupção. Quando uma NIC recebe um pacote, a NIC aciona um hardIRQ para notificar um kernel sobre a chegada do pacote. Depois disso, uma solicitação de interrupção de software (softIRQ) é agendada para processamento subsequente do protocolo. Como os hardIRQs têm alta prioridade, quando ocorre um hardIRQ, um processo em execução no núcleo da CPU é interrompido e o trabalho em andamento é evacuado para a área de memória, portanto, essa sobrecarga é significativa. Quando a frequência de chegada de pacotes é alta, muitos hardIRQs são gerados e a sobrecarga causada pelos hardIRQs resulta na degradação do desempenho. Para superar esse problema, a New API (NAPI) [14], adotada de uma versão mais recente do kernel 2.4.20, utiliza um método híbrido de modo de interrupção e modo de polling. Quando a frequência de chegada de pacotes é alta, a NAPI suprime hardIRQs e um thread do kernel pesquisa um buffer de recebimento. No entanto, o processamento subsequente do protocolo é executado em um contexto softIRQ. O NAPI não pode evitar a competição softIRQ e atrasos em escala ms [10], portanto, o NAPI não pode atender ao requisito (A).
O Data Plane Development Kit (DPDK) [15] fornece uma estrutura de recebimento de pacotes no modo polling. Os threads de pesquisa no espaço do usuário verificam constantemente a chegada de pacotes e os transferem imediatamente para um programa do usuário. Como o DPDK ignora uma pilha de protocolos do kernel e não gera nenhuma interrupção, ele pode atingir baixa latência. No entanto, como os threads de pesquisa no espaço do usuário verificam constantemente a chegada de pacotes, independentemente de os pacotes chegarem ou não, esse método consome mais energia e não pode atender ao requisito (B). Além disso, para usar o DPDK, uma função de polling e funções de protocolo de rede, como camada 2 (L2)/camada 3 (L3)/camada 4 (L4), precisa ser integrada a um programa do usuário. Assim, o DPDK não pode atender ao requisito (C).
l3fwd-potência [16] é um exemplo de aplicação DPDK para baixo consumo de energia. l3fwd-potência fornece vários modos de aplicação. Em APP_MODE_INTERRUPT, l3fwd-potência usa um método híbrido de recebimento de pacotes de um modo de interrupção e um modo de pesquisa. Quando nenhum pacote chega durante 10 ciclos consecutivos de polling, o intervalo de polling é esparso colocando uma instrução de pausa no loop de polling. Depois disso, quando nenhum pacote chegar durante 300 ciclos consecutivos de polling, o thread de polling será colocado em suspensão. Quando um pacote chega após o thread de pesquisa ter entrado no estado de suspensão, eventofd chama o thread de sondagem e reinicia a sondagem. Uma vez que esta lógica de suspensão se destina a seguir flutuações de tráfego lentas, como a escala das marés, e não é adequada para suspensão de alta frequência, o efeito de poupança de energia é limitado quando a frequência de flutuação de tráfego é elevada. Além disso, este APP_MODE_INTERRUPT não tem uma função para controlar dinamicamente a frequência da CPU dos núcleos da CPU usados pelos threads de pesquisa. Em APP_MODE_LEGACY, l3fwd-potência usa apenas o modo de pesquisa. Nesse modo, os threads de sondagem ficam suspensos e controlam dinamicamente a frequência da CPU dos núcleos da CPU usados pelos threads de sondagem quando nenhum pacote chega. Como este modo não possui uma função para reinicialização rápida de threads de polling, como um modo de interrupção, ele pode causar grandes atrasos e não atender ao requisito (A). Em ambos APP_MODE_INTERRUPT e APP_MODE_LEGACY, para usar funções de recebimento de pacotes de l3fwd-potência, uma função de polling e funções de protocolo de rede, como L2/L3/L4, precisam ser integradas a um programa de usuário e isso não pode atender ao requisito (C).
Li et al. [17] formularam a relação entre a utilização do núcleo da CPU usado por um thread de polling e o atraso no encaminhamento de pacotes. Quando a utilização da CPU está abaixo de um valor constante, como 80%, reduz a frequência da pesquisa adicionando uma pequena pausa. Uma vez que este método se destina a seguir flutuações de tráfego lentas, tais como escala de marés em ligações de baixa velocidade e não é adequado para suspensão de alta frequência, o efeito de poupança de energia é limitado quando a frequência de flutuação de tráfego é elevada. Além disso, como este método se destina a ser aplicado a uma solução DPDK, uma função de sondagem e funções de protocolo de rede, como L2/L3/L4, precisam ser integradas a um programa de usuário e isso não pode atender ao requisito (C).
Busy Poll Sockets (BPS) [18] fornece um método híbrido de recebimento de pacotes de um modo de interrupção e um modo de polling, adotado a partir de uma versão mais recente do kernel 3.11. Quando um aplicativo chama um SO_BUSY_POLL opção de soquete e define o tempo para sondagem ocupada, a sondagem ocupada é executada para receber pacotes para o período especificado. Exceto pelo período especificado, o recebimento de pacotes baseado em softIRQ é executado. Se uma aplicação não souber quando os pacotes chegarão, a pesquisa de ocupado não poderá ser realizada de acordo com o tempo de chegada do pacote. Assim, este método não é adequado para tráfego onde o tempo de chegada do pacote não pode ser previsto. Além disso, como uma aplicação precisa incluir uma função para especificar o período de tempo para polling ocupado, isso não pode atender ao requisito (C).
AF_XDP [19] é um novo tipo de soquete para processamento de quadros brutos, adotado de uma versão mais recente do kernel 4.18. Como um aplicativo pode receber quadros brutos por meio de um soquete AF_XDP sem uma pilha de protocolos do kernel, o AF_XDP fornece um caminho de dados rápido. No entanto, como AF_XDP é um caminho de dados de recepção de pacotes em modo de interrupção e notifica uma aplicação sobre a chegada de um quadro em um contexto de NET_RX_SOFTIRQ, não pode evitar a competição softIRQ e atrasos em escala ms. Assim, AF_XDP não pode atender ao requisito (A). Além disso, para usar AF_XDP, funções de protocolo de rede, como L2/L3/L4, precisam ser integradas a uma aplicação e isso não pode atender ao requisito (C).
KBP [10] aprimora um kernel para fornecer rede de baixa latência, permitindo o recebimento de pacotes no modo polling. Como o KBP lança threads de kernel para realizar pesquisas ocupadas em vez de receber pacotes baseados em softIRQ e evita competições de softIRQ, o KBP pode atingir baixa latência na ordem de μs para encaminhamento de pacotes. Além disso, o KBP não modifica a pilha de protocolos do kernel existente, portanto, a modificação do aplicativo é desnecessária. Além disso, como as funções do KBP são aplicadas aos kernels existentes usando um livepatch do kernel, o redesenvolvimento do software para cada atualização de segurança do kernel é desnecessário. No entanto, os threads de pesquisa ocupam os núcleos da CPU e evitam que os threads hibernem, o que incorre em maior uso de energia e não pode atender ao requisito (B).
IX [20] fornece um recurso de rede de execução até a conclusão em um kernel para baixa latência. Zygos [21] fornece o escalonador original, e Shenango [22] e Shinjuku [23] fornecem algoritmo de interrupções entre processadores em um kernel para baixa latência. Essas soluções exigem que partes principais de um kernel sejam modificadas e não atendem ao requisito (D).
DMM lwIP [24] e Slim [25] fornecem soluções de encaminhamento de pacotes de baixa latência. Para adicionar funções especiais a uma pilha de protocolos do kernel sem modificar um kernel, essas soluções usam a estrutura LD_PRELOAD. A estrutura LD_PRELOAD permite que um aplicativo use funções personalizadas sequestrando lib.c bibliotecas, como soquete.c. Esta estrutura precisa implementar funções personalizadas em um aplicativo para interoperar as funções especiais e isso não pode atender ao requisito (C).
3. Análise de Baixa Latência e Economia de Energia
Discutimos os fatores e mecanismos que causam atrasos no encaminhamento de pacotes usando o método atual de encaminhamento de pacotes NAPI como exemplo. A Figura 1 mostra a arquitetura do NAPI. Para o lado receptor (Rx), quando uma NIC recebe um pacote, a NIC copia os dados do pacote no espaço de memória do host por acesso direto à memória (DMA) sem usar recursos da CPU. Para relatar a chegada do pacote, a NIC invoca um hardIRQ e registra as informações do dispositivo de rede em um lista_enquete no contexto hardIRQ. Depois disso, um softIRQ é programado para pesquisar pacotes do lista_enquete e executa processamento de protocolo subsequente, como Ethernet, IP e UDP. Como o hardIRQ tem prioridade extremamente alta e outros processos não podem usar o núcleo da CPU durante seu contexto, o processamento pesado não deve ser alocado em um contexto do hardIRQ para estabilidade do sistema. Assim, esses processos pesados de protocolo são executados no contexto softIRQ. No entanto, este softIRQ de NET_RX_SOFTIRQ pode ser competido por outros softIRQs, como interrupções de temporizador local e ata_piix e ksoftirqd agenda esses softIRQs, que devem esperar até o horário agendado. Além disso, quando ksoftirqd não tem tempo de CPU suficiente, o agendamento do softIRQ está atrasado. Esta competição softIRQ causa atrasos em escala ms, conforme discutido em trabalhos anteriores [10]. Essa competição softIRQ pode ocorrer em um kernel em uma configuração bare-metal, em um kernel host em uma configuração de contêiner e em um kernel host e um kernel convidado em uma configuração de VM. Como essa competição de softIRQ não pode ser evitada por nenhum ajuste de kernel, são necessárias mudanças na arquitetura para obter um caminho de dados de baixa latência. Para o lado da transmissão (Tx), como o pacote é transmitido sem qualquer interrupção depois que um aplicativo envia um pacote, um kernel não incorre em nenhum atraso na escala de ms.
Métodos de recebimento de pacotes no modo polling, como DPDK, BPS e KBP, são adequados para evitar a competição softIRQ. Como um método de recebimento de pacotes no modo polling pode detectar a chegada de pacotes rapidamente por meio de polling ocupado, não há necessidade de relatar a chegada de pacotes por meio de interrupções. Assim, os métodos de recebimento de pacotes no modo polling não incorrem na competição softIRQ de NET_RX_SOFTIRQ. Entretanto, o DPDK precisa de uma função de polling e funções de protocolo de rede, como L2/L3/L4, para ser integrado a um programa de usuário. O BPS precisa de uma função integrada que especifique o período de tempo para polling ocupado. Portanto, o DPDK e o BPS não podem atender ao requisito (C). Para obter um método de recebimento de pacotes no modo polling que não exija modificação do aplicativo, os threads de polling precisam ser integrados em um kernel. No entanto, como há uma restrição de que vários processos softIRQ não podem ser executados em um núcleo de CPU, e a implementação de um processo de protocolo de rede, que é executado em um contexto softIRQ na NAPI, com um thread de pesquisa requer deadlock de softIRQs, o que é um desafio. KBP, nosso trabalho anterior, conforme mostrado na Figura 2, possui threads de pesquisa em um kernel e recurso de controle de deadlock de softIRQs, e não altera a pilha de protocolo de pacotes do kernel existente e a API de soquetes POSIX, permitindo assim o encaminhamento de pacotes de baixa latência e tornando desnecessária a modificação do aplicativo. Além disso, o KBP pode ser aplicado ao NAPI existente por um livepatch do kernel, uma vez que o KBP oferece essas funções de pesquisa com poucas alterações no NAPI. Assim, o KBP atende aos requisitos (A), (C) e (D). No entanto, como os threads de sondagem sempre realizam sondagens ocupadas, independentemente de os pacotes terem chegado ou não, o KBP desperdiça recursos da CPU e aumenta o consumo de energia. Assim, o KBP não atende aos requisitos de (B).
Como o KBP pode atender aos requisitos (A), (C) e (D), se o KBP puder ser melhorado para atender ao requisito (B), então todos os requisitos poderão ser satisfeitos. A ideia básica para economizar energia é colocar os threads de polling em suspensão enquanto nenhum pacote chega. O tempo de chegada dos pacotes costuma ser imprevisível para aplicações em tempo real, como VR, jogos on-line, drones controlados remotamente e carros autônomos. Por exemplo, em VR, é difícil prever quando um usuário moverá seu olhar, por isso é difícil prever quando as informações de olhar do head-mounted display chegarão ao servidor. Portanto, é difícil controlar o tempo de threads de pesquisa suspensos usando um cronômetro. É desejável que uma solução também possa ser aplicada ao tráfego onde o tempo de chegada dos pacotes é imprevisível. Assim, neste artigo, tentamos encontrar uma maneira de despertar threads de polling adormecidos rapidamente após a chegada de um pacote, como discutiremos na Seção. 4. Além disso, simplesmente colocar o thread de pesquisa em suspensão terá apenas um efeito limitado de economia de energia. Mesmo que os threads de pesquisa parem de pesquisar ocupados e chamem a CPU pausa instrução, o núcleo da CPU continua a ler e executar a instrução de um contador de programa e registra a próxima instrução para evitar que ocorra violação da ordem de memória. Isso significa que a fonte de alimentação do núcleo da CPU não irá parar e o núcleo da CPU continuará operando e consumindo ciclos da CPU. Como menos ciclos de CPU são consumidos pela instrução de pausa do que pela pesquisa ocupada, o consumo de energia do núcleo da CPU pode ser reduzido interrompendo a pesquisa ocupada. No entanto, o efeito de poupança de energia é limitado, uma vez que o núcleo da CPU não para de funcionar. Como métodos para aumentar o efeito de economia de energia, tecnologias de gerenciamento de energia, escala dinâmica de tensão e frequência (DVFS) e baixa potência ociosa (LPI) são implementadas nas CPUs. O DVFS controla dinamicamente a tensão da fonte de alimentação e a frequência operacional dos núcleos da CPU em resposta a mudanças na carga e na temperatura. O LPI controla o estado de suspensão do núcleo da CPU quando o núcleo está inativo e costuma ser chamado de estado C. O LPI permite que alguns circuitos nos núcleos sejam desligados enquanto não há carga da CPU. DVFS e LPI são implementados e usados em quase todas as CPUs modernas. Como a maioria dessas funções, incluindo LPI, são operadas pelo controle de hardware das CPUs, esses efeitos de economia de energia podem ser obtidos apenas reduzindo a carga da CPU, colocando os threads de pesquisa em suspensão. Quando os threads de pesquisa entram em suspensão e a carga da CPU cai, a CPU aprofunda autonomamente o estado de suspensão dos núcleos da CPU por LPI sob controle de hardware. No entanto, essas funções podem causar atrasos no processamento durante a recuperação de um estado inativo, aumentando a latência da rede. Como o LPI pode ser ativado/desativado ativando/desativando o estado C, na avaliação de desempenho na Seção. 5, usamos um processador Intel Xeon para avaliar o efeito de economia de energia e a latência da rede, controlando os threads de pesquisa para hibernar para cada caso de estado C LIGADO/DESLIGADO. Além disso, a frequência operacional da CPU pode ser controlada usando o governador de frequência da CPU [26] de um kernel. Se a frequência operacional da CPU puder ser controlada de acordo com o tempo de chegada dos pacotes, bem como um controle de suspensão dos threads de pesquisa, poderão ser esperados efeitos adicionais de economia de energia. Assim, tentamos controlar a frequência operacional da CPU com um controle de suspensão de threads de polling, conforme discutimos na Seção. 4.
4. Arquitetura de KBP com Eficiência Energética
Projetamos e implementamos um sistema de rede de baixa latência e eficiência energética, KBP energeticamente eficiente (EE-KBP), que atende a todos os requisitos: (A) baixa latência na ordem de μs para encaminhamento de pacotes em um servidor virtual, (B) ) menor consumo de energia do que as soluções existentes, (C) não há necessidade de modificação do aplicativo e (D) não há necessidade de redesenvolvimento de software para cada atualização de segurança do kernel. Como o KBP é um sistema de rede de baixa latência que pode satisfazer os requisitos (A), (C) e (D), adotamos o KBP como sistema base e tentamos reduzir o consumo de energia para atender ao requisito (B). Conforme discutido na Seção. 3, os threads de polling do KBP têm maior consumo de energia, uma vez que a polling ocupada é realizada independentemente de os pacotes chegarem ou não. Assim, a ideia básica para economizar energia é colocar os threads de polling em suspensão enquanto nenhum pacote chega. A Figura 3 mostra a arquitetura de alto nível do EE-KBP. Para reduzir o consumo de energia dos threads de polling, o EE-KBP possui uma função de controle de suspensão para um thread EE-KBP e uma função de controle de frequência da CPU para um núcleo da CPU que é usado por um thread de polling. EE-KBP tem quatro pontos novos. A primeira é que o EE-KBP ativa um thread de polling e retoma a polling rapidamente usando o contexto de hardIRQ quando um pacote chega enquanto o thread de polling está adormecido para não comprometer a baixa latência (consulte a Seção 4.1). A segunda é que o EE-KBP controla dinamicamente a frequência operacional da CPU de um kernel para aumentar o efeito de economia de energia de um thread de pesquisa adormecido (consulte a Seção 4.2). A terceira é que o EE-KBP possui uma lógica de controle de conflitos para executar essas funções em um kernel, uma vez que um kernel tem uma restrição de que vários processos softIRQ não podem ser executados simultaneamente no mesmo núcleo da CPU (consulte a Seção 4.1). A quarta é que essas funções podem ser aplicadas ao kernel existente por um livepatch do kernel, uma vez que essas alterações no kernel existente foram feitas tão pequenas quanto possível (veja Seção 4.3).
Este EE-KBP pode ser implantado em um kernel host para um servidor bare-metal. Além disso, o EE-KBP pode ser implantado em um kernel host e um kernel convidado para uma configuração de VM, como mostrado na Fig. 4, e em um kernel host para configuração de contêiner, como mostrado na Fig. pode causar uma falta de tempo de CPU de ksoftirqd devido às sobrecargas de emulação de uma VM, que podem causar latência em escala ms, o EE-KBP para um kernel convidado é altamente eficaz na redução da latência. De acordo com nosso trabalho anterior [10], uma vez que um kernel host de uma configuração de contêiner em Kubernetes [27] cluster também pode causar falta de tempo de CPU de ksoftirqd devido a um Kubernetes agendador e outros threads relacionados, que podem causar latência em escala ms, EE-KBP para um kernel host é eficaz na redução da latência.
Para obter baixa latência usando EE-KBP, um thread EE-KBP deve ter um núcleo de CPU dedicado e nenhum outro processo deve coexistir no núcleo da CPU onde o thread EE-KBP é executado. Como as CPUs modernas têm muitos núcleos de CPU, essa limitação não é uma grande desvantagem, mas espera-se que o EE-KBP seja difícil de aplicar a um computador de placa única com um pequeno número de núcleos de CPU, como o Raspberry Pi.
4.1 Algoritmo Híbrido de Pesquisa de Sono e Ocupado
Se a pesquisa ocupada por threads de pesquisa puder dormir enquanto nenhum pacote estiver chegando, o aumento no consumo de energia por threads de pesquisa poderá ser reduzido. No entanto, a sobrecarga de threads de pesquisa em suspensão pode aumentar o tempo de atraso no recebimento de pacotes. Tentamos controlar a suspensão dos threads de pesquisa sem comprometer ao máximo a baixa latência. Primeiro, precisamos projetar quando colocar um thread de pesquisa em suspensão e quando ativá-lo. A Figura 6 mostra um modelo de tráfego simplificado que descreve o tempo em que os pacotes chegam. Idealmente, um thread de polling deve ser ativado quando um pacote chega e dormir quando um pacote para de chegar. No entanto, conforme discutido na Seç. 3, uma vez que o tempo de chegada do pacote é muitas vezes imprevisível para aplicações em tempo real, é difícil prever o tempo de chegada do pacote e ativar um thread de pesquisa antecipadamente com um temporizador. Além disso, quando os pacotes chegam em sucessão, é difícil prever quando a chegada dos pacotes irá parar, portanto também é difícil prever quando suspender o thread de pesquisa. Para o método de despertar um thread de polling, o EE-KBP desperta o thread de polling o mais rápido possível depois que o pacote chega à NIC. HardIRQ tem prioridade extremamente alta e quando o hardIRQ é acionado, um processo em execução em um núcleo da CPU deve suspender e ceder tempo de CPU ao hardIRQ. Quando uma NIC recebe um pacote, a NIC notifica um kernel de que um pacote chegou, gerando um hardIRQ. Assim, usar este contexto hardIRQ permite que o thread de pesquisa seja ativado rapidamente. Quanto a quando colocar o tópico de votação para dormir, lista_enquete pode ser usado para julgar se deve dormir ou não. Quando uma NIC recebe um pacote, a NIC registra seu dispositivo de rede em um lista_enquete e um kernel pode reconhecer se há um pacote para receber ou não, verificando o lista_enquete. Contanto que o dispositivo de rede esteja registrado no lista_enquete, significa que os pacotes não processados estão sendo armazenados em buffer, portanto, o thread de sondagem deve continuar a sondagem. Quando o dispositivo de rede não existe no lista_enquete, significa que não há nenhum pacote a ser processado pelo thread de sondagem, portanto, o thread de sondagem pode interromper a sondagem e dormir. Assim, quando o dispositivo de rede não estiver cadastrado em um lista_enquete, o encadeamento EE-KBP interrompe a pesquisa e dorme.
O Algoritmo 1 mostra um algoritmo híbrido de pesquisa de sono e ocupado para EE-KBP. Para desabilitar um softIRQ para rede de NAPI para evitar a competição de softIRQ, que causa atrasos, o EE-KBP remove uma função de gerar um softIRQ de NET_RX_SOFTIRQ in netif_rx. Em vez disso, o EE-KBP adicionou uma função para ativar um thread EE-KBP em um contexto de hardIRQ para rede em netif_rx. Um thread EE-KBP é um thread do kernel que realiza polling ocupado para receber pacotes e dorme quando não há nenhum dispositivo de rede registrado no lista_enquete. Ao combinar modificado netif_rx e o thread EE-KBP, o thread EE-KBP realiza polling ocupado para receber pacotes com baixa latência enquanto há pacotes não recebidos, o thread EE-KBP dorme quando lista_enquete fica vazio para reduzir o consumo de energia e quando um pacote chega enquanto o thread EE-KBP está adormecido, um manipulador de um hardIRQ de chegada de pacote acorda o thread EE-KBP para retomar rapidamente a pesquisa ocupada. Q (cota) é o valor do número de pacotes a serem recebidos em uma votação, e o valor padrão do NAPI do kernel existente é 64. Este valor é usado na avaliação de desempenho como será discutido na Seção. 5.
Há uma restrição de que vários processos softIRQ não podem ser executados simultaneamente no mesmo núcleo da CPU. Na NAPI do kernel existente, os processos de protocolo de rede são processados em um contexto softIRQ. Como o EE-KBP usa uma pilha de protocolos de rede existente em um kernel para atender aos requisitos (C) e (D), o EE-KBP não faz nenhuma alteração nas funções após netif_receive_skb. Assim, precisamos considerar esta restrição quando o thread EE-KBP puxa um pacote e prossegue para o processamento do protocolo de rede. Para controlar esta restrição de proibição de execução de múltiplos softIRQs, o EE-KBP possui uma lógica de controle de conflitos. Depois que o encadeamento EE-KBP extrai um pacote, o encadeamento EE-KBP proíbe outros softIRQs e prossegue para o processamento subsequente do protocolo de rede. Após o término do processamento do protocolo, o EE-KBP libera esta proibição.
4.2 Recurso de controle de frequência da CPU
Para reduzir ainda mais o consumo de energia de um núcleo de CPU enquanto um thread EE-KBP está em suspensão, o EE-KBP controla dinamicamente a frequência operacional da CPU do núcleo da CPU. Conforme discutido na Seção. 3, mesmo que um thread de pesquisa pare de pesquisar ocupado e durma, o núcleo da CPU continua a ler e executar uma instrução de um contador de programa e registra a próxima instrução para evitar violação da ordem de memória. Isso significa que o núcleo da CPU continua consumindo energia enquanto o thread de pesquisa está inativo. Como a frequência operacional de um núcleo da CPU pode ser alterada dinamicamente a partir de um kernel, espera-se reduzir esse desperdício de energia do núcleo da CPU diminuindo a frequência operacional da CPU enquanto o thread de pesquisa está inativo. EE-KBP tem uma função de controle de frequência da CPU e define a frequência operacional da CPU do núcleo da CPU para baixo quando o thread EE-KBP dorme e restaura a frequência operacional da CPU quando ela acorda do sono, conforme mostrado no algoritmo 1. EE -KBP usa o regulador de frequência da CPU para alterar a frequência operacional da CPU. Existem vários tipos de política de governador, como “desempenho”, “economia de energia”, “espaço do usuário” e “sob demanda”. Usamos o regulador de frequência da CPU “userspace”, pois ele permite que uma frequência específica seja definida para um núcleo da CPU. Ao usar o “espaço do usuário” do regulador de frequência da CPU, o encadeamento EE-KBP define a frequência máxima da CPU no tempo acionado por um hardIRQ de rede e define a frequência mínima da CPU logo antes do encadeamento EE-KBP entrar em suspensão. O intervalo de tempo entre a alteração da frequência operacional da CPU e a alteração refletida no núcleo da CPU precisa ser curto, da ordem de μs, mas determinamos que ele é curto o suficiente com base nos resultados da avaliação de desempenho, como será discutido na Seção. 5.
Quanto às funções de economia de energia por controle de hardware que muitas CPUs possuem, como DVFS e LPI (C-state), sua operação não pode ser controlada a partir de um kernel, mas essas funções podem ser ativadas apenas colocando um thread de polling em suspensão, conforme discutido na seita. 3. Assim, o EE-KBP não possui um recurso para controlar essas funções de hardware da CPU, mas o EE-KBP altera a taxa de utilização de um núcleo da CPU controlando o estado de suspensão de um thread de pesquisa, o que aumenta indiretamente a eficácia desses poder -funções de economia. O efeito dessas funções e o longo tempo de atraso devido à sobrecarga serão discutidos na avaliação de desempenho na Seção. 5.
4.3 Aplicando pelo Kernel Livepatch
Os recursos do EE-KBP podem ser habilitados fazendo algumas alterações no NAPI de um kernel existente. Conforme mostrado no algoritmo 1, EE-KBP apenas remove a função de gerar um softIRQ de NET_RX_SOFTIRQ e adiciona a função de ativar o thread EE-KBP em netif_rx do NAPI. O thread EE-KBP é ativado por netif_rx, e depois de extrair pacotes, ele passa o processo para netif_receive_skb. Assim, a menos que netif_rx or netif_receive_skb for alterado, o EE-KBP pode ser executado em qualquer versão do kernel após a versão 2.4.20, quando o NAPI foi implementado. Um kernel possui um mecanismo chamado kernel livepatch, que é usado para aplicar patches de segurança a um kernel ou alterar alguns comportamentos de um kernel. Como o EE-KBP precisa de algumas alterações do NAPI, o EE-KBP pode ser aplicado por um livepatch do kernel. Se ocorrer uma atualização de segurança em um kernel, o EE-KBP pode ser habilitado simplesmente aplicando o livepatch do kernel a uma nova versão do kernel novamente. Assim, a menos que netif_rx or netif_receive_skb for alterado, os provedores de serviços não precisarão modificar o software do livepatch do kernel. Além disso, como o livepatch do kernel pode ser aplicado sem reinicializar o sistema, os provedores de serviços podem aplicar o EE-KBP sem interrupção do serviço.
4.4 Escalando
Se a quantidade de tráfego de entrada for muito grande para ser tratada por um único thread EE-KBP, vários threads EE-KBP poderão ser implementados em um kernel. Quase todas as NICs modernas possuem um recurso de dimensionamento do lado de recepção (RSS) e usam vários núcleos de CPU para recebimento de pacotes. Quando uma NIC recebe um pacote, ela escolhe em qual núcleo da CPU invocar um hardIRQ. A expansão pode ser obtida iniciando threads EE-KBP em vários núcleos de CPU e vinculando esses núcleos de CPU aos núcleos de CPU para os quais os hardIRQs são gerados por RSS.
5. Avaliação de Desempenho
Para avaliar o efeito da economia de energia e da baixa latência do EE-KBP, realizamos avaliações de desempenho comparando o EE-KBP com o NAPI existente e o KBP adotado como máquina base do EE-KBP. Medimos o consumo de energia, a latência de encaminhamento de pacotes e a taxa de transferência quando a carga de tráfego foi adicionada às soluções de destino. Conforme discutido na Seção. 4, o EE-KBP pode ser implantado em um kernel host para um servidor bare-metal, em um kernel host e um kernel convidado para uma configuração de VM e em um kernel host para configuração de contêiner. Em uma configuração de VM, um host e um convidado têm, cada um, um thread de pesquisa e, como o número de threads de pesquisa a serem suspensos pelo EE-KBP é maior do que em um servidor bare-metal ou em uma configuração de contêiner, o efeito de economia de energia pode ser amplamente medido. Além disso, em uma configuração de VM, como os atrasos no encaminhamento de pacotes provavelmente serão longos devido a uma sobrecarga de emulação para criar uma VM, o efeito de baixa latência com EE-KBP pode ser amplamente medido. Por esses motivos, utilizamos uma configuração de VM para avaliações de desempenho. Para avaliar o efeito do recurso de controle de suspensão do EE-KBP com recursos de economia de energia da CPU controlados por hardware, avaliamos cada caso quando o estado C foi ativado e desativado. Além disso, para avaliar o efeito do recurso de controle de frequência da CPU do EE-KBP, avaliamos se cada caso em que o recurso de controle de frequência da CPU foi habilitado e desabilitado. Assim, conduzimos avaliações comparativas de soluções e configurações para (a) NAPI, (b) KBP, (c) EE-KBP quando o estado C foi desativado e o recurso de controle de frequência da CPU foi desativado, (d) EE-KBP com O estado C foi desabilitado e o recurso de controle de frequência da CPU foi habilitado, (e) E-KBP quando o estado C foi habilitado e o recurso de controle de frequência da CPU foi desabilitado, e (f) EE-KBP quando o estado C foi habilitado e o recurso de controle de frequência da CPU foi ativado.
A Tabela 1 mostra as especificações da plataforma experimental. Para baixa latência, os núcleos de CPU usados para processamento de pacotes foram configurados para um governador de alto desempenho e threads de emulação de CPU virtual de máquina virtual baseada em kernel (KVM) e rede vhost foram alocados núcleos de CPU dedicados e isolados de outros processos usando isolco. Para economia de energia, o C-state foi habilitado para (a) NAPI e (b) KBP. Para o recurso de controle de frequência da CPU do EE-KBP em (d) e (f), um governador de “espaço do usuário” foi usado, e a frequência máxima que poderia ser definida para o processador Intel Xeon usado era 2.8 GHz, e a frequência mínima era 1.2 GHz.
Adicionamos uma carga de tráfego de ida e volta conforme mostrado na Fig. 7. Como o protocolo de controle de transmissão (TCP) tem controle de retransmissão e controle de congestionamento, e o efeito do recurso de controle de sono do EE-KBP é difícil de avaliar, usamos UDP tráfego. Para avaliar o efeito de economia de energia e o aumento do tempo de atraso devido ao overhead de despertar do sono do EE-KBP, variando o tempo em que os threads de polling estavam adormecidos, foram utilizadas seis condições de tráfego com diferentes taxas de tráfego e tamanhos de quadro. mostrado na Tabela 2. Nessas condições de tráfego, um pacote chega no intervalo de chegada do pacote descrito na Tabela 2. Quando um pacote chega, um thread de polling é acordado por um hardIRQ da chegada do pacote e dorme imediatamente depois disso, e isso o processo é repetido conforme mostrado na Fig. 6. Não é possível extrair pacotes continuamente por poll ocupado. Estas condições de tráfego são desvantajosas para EE-KBP. No entanto, estas são condições de tráfego adequadas para avaliar a sobrecarga causada pelo sono do thread de pesquisa do EE-KBP. 80 Mbps é a taxa de tráfego na qual não ocorre perda de pacotes em nenhuma das soluções comparadas.
5.1 Consumo de energia
Existem três métodos para medir o consumo de energia de um servidor. A primeira é medir fisicamente o consumo de energia de um servidor inteiro, inserindo um medidor de energia em uma linha de alimentação do servidor. Este método não depende da precisão de um sensor de um servidor e pode medir o consumo de energia com alta precisão. No entanto, é necessário trabalho no local para instalar um medidor de energia e verificar os valores de medição de um medidor de energia. Como desta vez foi difícil realizar trabalho no local por muito tempo, usamos esse método apenas para verificar a precisão da medição de um método descrito abaixo. A segunda é usar a interface de limite de potência média de execução (RAPL) da Intel. A CPU da Intel fornece uma interface RAPL que permite obter informações de consumo de energia. É relatado que o RAPL fornece dados de consumo de energia de alta precisão da CPU [28] e memória dinâmica de acesso aleatório (DRAM). Entretanto, o consumo de energia de um servidor inteiro não pode ser medido usando uma interface RAPL. Como o desempenho e o consumo de energia dos núcleos da CPU estão intimamente relacionados à velocidade do ventilador de resfriamento do chassi do servidor, é necessário avaliar o consumo de energia de um servidor inteiro que inclui o consumo de energia dos ventiladores de resfriamento. A terceira é usar uma interface de gerenciamento de plataforma inteligente (IPMI). IPMI permite que um servidor seja controlado e monitorado remotamente. Ao usar este IPMI, podemos medir o consumo de energia de um servidor inteiro. No entanto, foi relatado que a precisão da medição do consumo de energia usando um IPMI é baixa em alguns casos, dependendo da precisão dos sensores integrados de um servidor [29]. Assim, comparamos os resultados da medição de potência entre o uso de um IPMI e um medidor de potência para verificar a precisão de um sensor integrado em um servidor (Dell PowerEdge R730). O resultado da medição pelo IPMI foi 0.29% menor que o resultado da medição pelo medidor de potência e a diferença entre os dois ficou estável, portanto concluímos que a precisão das medições de potência do IPMI para este servidor foi alta o suficiente. Medimos o consumo de energia de cada solução e configuração quando foi adicionado tráfego com as condições descritas na Tabela 2. Para adicionar essas condições de tráfego, utilizamos um Spirent Test Center SPT-N4U (STC) como testador de desempenho. Adicionamos uma carga de tráfego e medimos o consumo de energia por 60 segundos e repetimos a medição 5 vezes.
A Figura 8 mostra os resultados da medição do consumo de energia de cada solução e configuração ao longo do tempo. Começamos a aplicar tráfego 10 segundos depois de iniciarmos o teste e depois continuamos aplicando tráfego por 60 segundos. Primeiro, analisamos o aumento no consumo de energia devido à pesquisa ocupada de um thread de pesquisa comparando os resultados de (a) NAPI e (b) KBP. Comparando os resultados do consumo de energia sem tráfego aplicado, (a) NAPI foi de 170 watts (W) e (2) KBP foi de 181 W, uma diferença de 11 W. Em uma configuração de VM com KBP, havia um thread de pesquisa em cada de um host e um convidado, o que significa que o consumo incremental de energia da pesquisa ocupada pelos dois threads de pesquisa foi de 11 W. Assim, o consumo de energia devido à pesquisa ocupada inútil quando nenhum pacote estava chegando desperdiçou 5.5 W por thread de pesquisa. Quanto à análise do efeito do EE-KBP para colocar um thread de polling em hibernação, o consumo de energia de (e) e (f) com estado C habilitado foi de 170 W enquanto nenhum tráfego foi adicionado, o que foi o mesmo que ( a) NAPI. Esses resultados significam que o EE-KBP pode reduzir o consumo de energia para o mesmo nível que o NAPI enquanto nenhum pacote chega, colocando os threads de pesquisa em suspensão. Por outro lado, os resultados de (c) e (d), que são os resultados quando o estado C está desabilitado, mostram que o consumo de energia aumenta em cerca de 25 W, mesmo quando nenhum tráfego é adicionado. Como o estado C não pode ser alterado para cada núcleo da CPU, para toda a CPU, as funções de economia de energia controladas por hardware de todos os 14 núcleos da CPU foram desativadas, resultando em um grande aumento no consumo de energia. Se os provedores de serviços precisarem economizar energia, é desejável definir o estado C como ativado.
Em seguida, analisamos o efeito de economia de energia do EE-KBP enquanto o tráfego era adicionado. As Figuras 9 e 10 classificam os resultados de consumo de energia para cada solução e configuração por tamanho de quadro e taxa de tráfego. As Figuras 9 e 10 mostram os resultados com cargas de tráfego de 80 Mbps e 1 Gbps, respectivamente. Comparando os resultados de (b) KBP e (e) EE-KBP sem controle de frequência da CPU, o EE-KBP reduziu o consumo de energia em 3 W em todas as condições de tráfego em comparação com o KBP, colocando os threads de pesquisa em suspensão. Estes resultados de (e) EE-KBP foram quase iguais aos resultados de (a) NAPI. Isso significa que o EE-KBP resolve o problema de aumento do consumo de energia devido à pesquisa ocupada de threads de pesquisa no KBP. Além disso, comparando os resultados de (b) KBP e (f) EE-KBP com controle de frequência de CPU, EE-KBP com controle de frequência de CPU consumiu cerca de 5 a 7 W menos energia que KBP, exceto para 1 Gbps 64- condição de tráfego de bytes. A função de controle de frequência da CPU do EE-KBP reduz o consumo de energia em 2 a 4 W adicionais em comparação com os resultados em (e) EE-KBP sem controle de frequência da CPU. Ao controlar a frequência da CPU, bem como colocar os threads de pesquisa em suspensão, o EE-KBP poderia reduzir ainda mais o consumo de energia do que o NAPI. Na condição de tráfego de 1 Gbps e 64 bytes, o EE-KBP com controle de frequência da CPU não poderia reduzir ainda mais o consumo de energia do que o EE-KBP sem controle de frequência da CPU. Na condição de tráfego de 1 Gbps e 64 bytes, o intervalo de chegada de pacotes é de 0.5 μs, o que é bastante curto. Pensa-se que a alteração da frequência operacional da CPU pelo EE-KBP não foi refletida no tempo durante este curto intervalo. Na condição de tráfego de 1 Gbps e 512 bytes, uma vez que o EE-KBP com controle de frequência da CPU poderia reduzir ainda mais o consumo de energia do que o EE-KBP sem controle de frequência da CPU, foi mostrado que uma frequência operacional da CPU pode ser alterada na ordem de μs pela função de EE-KBP. Esses resultados estão em uma configuração de VM na qual há dois threads de pesquisa, que estão em um host e em um convidado. Ao fornecer serviços em tempo real, espera-se que um grande número de usuários seja acomodado no servidor, e o número de threads de pesquisa também deverá aumentar, de modo que o efeito de economia de energia do EE-KBP aumenta com cada thread de pesquisa adicional comparado com o KBP existente. Além disso, neste tráfego de teste, os pacotes chegaram continuamente e o tempo de suspensão foi curto, de modo que o efeito de economia de energia do EE-KBP foi limitado. Se o tráfego tiver um longo tempo de suspensão, como a entrada de pacotes intermitentes, o efeito de economia de energia do EE-KBP será ainda maior.
5.2 Latência
Para avaliar o aumento da latência de encaminhamento de pacotes no EE-KBP devido à sobrecarga do controle de sono e controle de frequência da CPU, medimos a latência máxima de ida e volta de cada solução e configuração quando o tráfego com as condições descritas na Tabela 2 foi adicionado. Para adicionar essas condições de tráfego e medir a latência, utilizamos o STC como testador de desempenho. Adicionamos uma carga de tráfego e medimos a latência por 60 segundos e repetimos a medição 5 vezes.
As Figuras 11 e 12 mostram a medição da latência com cargas de tráfego de 80 Mbps e 1 Gbps, respectivamente. Comparando os resultados de (b) KBP e (e) EE-KBP sem controle de frequência da CPU, embora a latência máxima de ida e volta tenha aumentado em até 87 μs em comparação com KBP, EE-KBP alcançou baixa latência na ordem de μs . Para o tráfego de 1 Gbps, o aumento no tempo de atraso do EE-KBP em comparação com o KBP foi pequeno, e para o tráfego de 80 Mbps, o aumento no tempo de atraso tendeu a ser maior. Como o tráfego de 80 Mbps tem um intervalo de pacotes mais longo e os threads de polling podem dormir por um período de tempo mais longo, presume-se que os threads de polling precisam de mais tempo para se recuperar devido ao sono profundo por um recurso de economia de energia de hardware de uma CPU. Embora a latência tenha aumentado ligeiramente devido à sobrecarga de colocar os threads de pesquisa em suspensão, o EE-KBP sem controle de frequência da CPU pode obter economia de energia sem comprometer a baixa latência. Com a condição de tráfego de 1 Gbps e 64 bytes, todas as soluções e configurações incorreram em atrasos e perdas de pacotes em escala ms. Isso se deve ao limite de desempenho de processamento de uma pilha de protocolos do kernel em um convidado, que é um limite de desempenho da arquitetura KBP sem quaisquer alterações na pilha de protocolos do kernel, conforme discutido em nosso trabalho anterior [10].
A seguir, analisamos o overhead causado pela função de controle de frequência da CPU do EE-KBP. Comparando os resultados de (e) EE-KBP sem controle de frequência de CPU e (f) EE-KBP com controle de frequência de CPU, (f) EE-KBP com controle de frequência de CPU alcançou baixa latência na ordem de μs, exceto para 64 quadros de -byte a 80 Mbps e 1 Gbps, embora a latência máxima de ida e volta tenha aumentado em até 260 μs em comparação com (e) EE-KBP sem controle de frequência da CPU. (f) EE-KBP com controle de frequência de CPU incorreu em atrasos em escala ms com quadros de 64 bytes a taxa de tráfego de 80 Mbps. Embora o intervalo de chegada de pacotes tenha sido menor para quadros de 512 bytes a 1 Gbps do que para quadros de 64 bytes a 80 Mbps, ocorreram atrasos em escala ms para quadros de 64 bytes a 80 Mbps. Esses atrasos se correlacionam com o número de tempos de hardIRQ que foram acionados por uma NIC. A Figura 13 mostra o número de hardIRQs quando o tráfego com cada condição descrita na Tabela 2 foi adicionado por 60 segundos. O número de hardIRQs em quadros de 64 bytes com taxa de tráfego de 80 Mbps foi o mais alto. Se o número de hardIRQs de chegada de pacotes for grande, um processo de recebimento de pacotes deverá ser interrompido em cada hardIRQ, os dados sendo processados deverão ser armazenados no espaço de memória e o tempo de CPU deverá ser repassado ao hardIRQ, resultando em uma grande sobrecarga. . Isso causou uma escassez de tempo de CPU para uma função de recebimento de pacotes executada no núcleo da CPU onde o thread EE-KBP operava, e como a função de controle de frequência da CPU também foi tentada no mesmo núcleo da CPU, o tempo de CPU foi ainda mais reduzido , resultando em atrasos no encaminhamento de pacotes em escala ms. Conforme discutido na Seção. 4.1, quando não há mais pacotes de dados a serem recebidos em um lista_enquete, um thread EE-KBP permite hardIRQ e entra em suspensão. Se a frequência de chegada de um pacote for relativamente escassa, um hardIRQ será acionado toda vez que um pacote chegar, portanto o número de hardIRQs se tornará alto. Se a frequência de chegada de um pacote for maior que a velocidade de recebimento e processamento de pacotes por uma pilha de protocolos do kernel, os pacotes subsequentes serão armazenados em um buffer de anel e o NET_DEV permanecerá no lista_enquete, portanto, o tempo em que o hardIRQ é proibido e o encadeamento continua a pesquisa será maior. Quando vários pacotes são armazenados no buffer de anel, o encadeamento EE-KBP recebe Q pacotes de uma vez para agrupá-los, então o buffer de anel ficará vazio novamente. O EE-KBP com estado C foi desativado e obteve menor latência máxima de ida e volta do que o EE-KBP com estado C foi ativado comparando os resultados de (c), (d), (e) e (f). No entanto, como a desativação do estado C causa um aumento significativo no consumo de energia, conforme discutido na Seção. 5.1, um caso de uso de desabilitação do estado C é considerado raro.
EE-KBP sem controle de frequência de CPU alcançou baixa latência na ordem de μs com pequena degradação de latência em comparação com KBP e o mesmo nível de efeito de economia de energia que NAPI usado no kernel existente, superando o problema de KBP, que é o aumento do consumo de energia por sondagem contínua e ocupada. Ao ativar a função de controle de frequência da CPU do EE-KBP, o EE-KBP reduziu ainda mais o consumo de energia para um nível inferior ao do NAPI e alcançou baixa latência na ordem de μs sob muitas condições de tráfego. No entanto, no caso de uma condição de tráfego em que o EE-KBP invocou muitos hardIRQs para rede, a latência máxima medida de ida e volta do EE-KBP com controle de frequência da CPU foi de 1.3 ms, notamos que esse valor foi menor que NAPI . Embora o número de hardIRQs no EE-KBP seja difícil de estimar, uma vez que o tempo de processamento de pacotes por uma pilha de protocolos do kernel varia dependendo do desempenho da CPU, comprimento do pacote e protocolo usado, o que afeta a velocidade com que os pacotes são extraídos de um buffer de anel, EE-KBP com controle de frequência de CPU pode ser usado para um serviço que possui tráfego composto por pacotes com intervalos de chegada de pacotes longos ou curtos.
5.3 Rendimento
Conduzimos uma avaliação de medição de rendimento para medir o desempenho máximo de rendimento sem perda de pacotes, conforme especificado na RFC2544 [30]. Usamos o Pktgen-DPDK [31] como gerador de tráfego e foi adicionado tráfego de quadros de 64, 512 e 1518 bytes. Adicionamos repetidamente tráfego do Pktgen-DPDK aumentando gradualmente a taxa de tráfego, medindo a taxa de transferência máxima sem perda de pacotes. Repetimos a medição cinco vezes.
A Figura 14 mostra os resultados das medições de rendimento. Comparando os resultados de (b) KBP, (e) EE-KBP sem controle de frequência de CPU e (f) EE-KBP com controle de frequência de CPU, EE-KBP teve apenas uma redução máxima de rendimento de 4.6% em comparação com KBP. Nos testes de rendimento, não há muitas oportunidades para os threads de pesquisa do EE-KBP dormirem, uma vez que um grande número de pacotes de teste é adicionado, portanto, o comportamento é quase o mesmo do KBP, onde os threads de pesquisa permanecem ocupados com a pesquisa. A degradação do desempenho da taxa de transferência para o KBP foi pequena, pois havia poucas oportunidades de sobrecarga devido ao controle de suspensão dos threads de pesquisa pelo EE-KBP. Comparado com o NAPI, o EE-KBP alcançou uma melhoria de rendimento de 1.4\(\times\) para 3.1\(\times\) mais alto. Os resultados de (c) e (d) com estado C desabilitado mostraram rendimento menor do que os resultados de (e) e (f) com estado C habilitado. Isso se deve a uma especificação do processador Intel Xeon usado, que tem uma frequência máxima de CPU de 2.4 GHz quando o estado C está desabilitado e 2.8 GHz quando o estado C está habilitado.
5.4 Discussão
Com base nos resultados nas seitas. 5.1 a 5.3 discutimos as características e o ajuste desejável do EE-KBP em relação ao desempenho. LPI (C-state) e controle de frequência da CPU são recursos independentes e os resultados da avaliação não revelaram nenhuma sinergia especial entre essas funções. Assim, um provedor de serviços que utiliza EE-KBP deve ativar/desativar essas funções de acordo com as diretrizes descritas abaixo. Quanto ao EE-KBP com estado C, o efeito de economia de energia com estado C habilitado foi grande, o tempo máximo de atraso com estado C habilitado piorou apenas algumas dezenas para 200 μs, e o rendimento foi melhor com estado C habilitado do que com C-state desabilitado. O EE-KBP com C-state habilitado foi superior ao NAPI em termos de economia de energia, baixa latência e rendimento em todas as condições de tráfego. Com base nesses resultados, quando um servidor precisa economizar energia, o C-state deve ser habilitado independentemente das condições de tráfego. Quanto ao EE-KBP com controle de frequência da CPU, o efeito de economia de energia e o rendimento foram maiores com controle de frequência da CPU do que sem ele. No entanto, no caso de tráfego com intervalos de chegada de pacotes onde muitos hardIRQs foram gerados em EE-KBP, atrasos na ordem ms ocorreram em ocasiões muito raras com controle de frequência da CPU. Para casos de uso em que um atraso de ordem ms muito raro é aceitável, o controle de frequência da CPU deve ser ativado, pois é possível obter maiores economias de energia. Para casos de uso em que um atraso muito raro na ordem ms é inaceitável, o controle de frequência da CPU deve ser desabilitado.
Como os atrasos na ordem ms raramente ocorrem com o controle de frequência da CPU, um provedor de serviços pode verificar se o tráfego de seu serviço atende a essa condição específica. No entanto, é altamente desafiador para um provedor de serviços adicionar tráfego e contar o número de hardIRQs para verificar se atendem a condições específicas. Além disso, o número de hardIRQs no EE-KBP é difícil de estimar, uma vez que o tempo de processamento de pacotes por uma pilha de protocolos do kernel varia dependendo do desempenho da CPU, do comprimento do pacote e do protocolo usado, o que afeta a velocidade com que os pacotes são extraídos de um anel. amortecedor. Assim, acreditamos que um recurso para suprimir o número de hardIRQs de acordo com as condições de tráfego é necessário para evitar atrasos na ordem ms. Este é o nosso trabalho futuro, como será discutido na Seção. 6.
6. Conclusão e estudo adicional
Projetamos e implementamos um sistema de rede de baixa latência e eficiência energética, kernel busy poll (EE-KBP), que atende a quatro requisitos: (A) baixa latência na ordem de μs para encaminhamento de pacotes em um servidor virtual, (B) menor consumo de energia do que as soluções existentes, (C) não há necessidade de modificação de aplicativos e (D) não há necessidade de redesenvolvimento de software para cada atualização de segurança do kernel. O EE-KBP alcança rede de baixa latência realizando polling ocupado em um kernel e economiza energia colocando threads de polling em suspensão enquanto nenhum pacote está chegando e controlando dinamicamente a frequência operacional dos núcleos da CPU para os threads de polling. O EE-KBP reduziu o consumo de energia em 1.5 W por thread de pesquisa em uma configuração de VM, controlando os threads de pesquisa para dormir, com apenas um aumento de 87 μs na latência em comparação com nosso KBP convencional, que mantém a pesquisa ocupada em um kernel. O EE-KBP alcançou rede de baixa latência da ordem de μs, enquanto consumia energia tão baixa quanto o NAPI adotado em um kernel atual. Além disso, ao controlar dinamicamente a frequência de um núcleo de CPU usado pelo thread de pesquisa do EE-KBP, o EE-KBP reduziu o consumo de energia em 2.5 a 3.5 W por thread de pesquisa em comparação com o KBP, e isso foi menor consumo de energia do que o NAPI. No entanto, devido à sobrecarga da função de controle de frequência da CPU, o EE-KBP causou um atraso de ida e volta de até 1.3 ms sob certas condições de tráfego, mas alcançou uma latência muito menor do que o NAPI. EE-KBP alcançou 1.4\(\times\) para 3.1\(\times\) rendimento mais alto do que o NAPI, e a degradação do desempenho do KBP foi limitada a 4.6% no máximo.
EE-KBP alcançou rede de baixa latência na ordem de μs na maioria das condições de tráfego e menor consumo de energia do que NAPI, mas a função de controle dinâmico de frequência da CPU causou um ligeiro atraso na ordem de ms para algumas condições de tráfego. Para trabalhos futuros, planejamos estudar o ajuste da função de controle de frequência da CPU pela contagem de hardIRQ de acordo com as condições de tráfego. Além disso, como medimos a eficácia do EE-KBP apenas em uma configuração de VM, planejamos avaliar sua eficácia em uma configuração bare-metal e em uma configuração de contêiner.
Referências
[1] S. Harcsik, A. Petlund, C. Griwodz, and P. Halvorsen, “Latency evaluation of networking mechanisms for game traffic,” Proc. 6th ACM SIGCOMM Workshop on Network and System Support for Games - NetGames’07, pp.129–134, 2007.
CrossRef
[2] M.S. Elbamby, C. Perfecto, M. Bennis, and K. Doppler, “Toward low-latency and ultra-reliable virtual reality,” IEEE Network, vol.32, no.2, pp.78–84, 2018.
CrossRef
[3] M.A. Lema, A. Laya, T. Mahmoodi, M. Cuevas, J. Sachs, J. Markendahl, and M. Dohler, “Business case and technology analysis for 5G low latency applications,” IEEE Access, vol.5, pp.5917–5935, 2017.
CrossRef
[4] R. Gupta, D. Reebadiya, and S. Tanwar, “6G-enabled edge intelligence for ultra-reliable low latency applications: Vision and mission,” Comp. Stand. Inter., vol.77, p.103521, 2021.
CrossRef
[5] M. Patel, B. Naughton, C. Chan, N. Sprecher, S. Abeta, and A. Neal, “Mobile edge computing introductory technical white paper,” 2014.
URL
[6] D.B. Oljira, A. Brunstrom, J. Taheri, and K.J. Grinnemo, “Analysis of network latency in virtualized environments,” IEEE Global Communications Conference (GLOBECOM), pp.1–6, 2016.
CrossRef
[7] P. Apparao, S. Makineni, and D. Newell, “Characterization of network processing overheads in Xen,” 2nd International Workshop on Virtualization Technology in Distributed Computing (VTDC), 2006.
CrossRef
[8] G. Aceto, V. Persico, A. Pescapé, and G. Ventre, “SOMETIME: Software defined network-based available bandwidth measurement in MONROE,” Proc. 1st Network Traffic Measurement and Analysis Conference, 2017.
CrossRef
[9] K. Suo, Y. Zhao, W. Chen, and J. Rao, “An analysis and empirical study of container networks,” IEEE INFOCOM 2018 - IEEE Conference on Computer Communications, pp.189–197, 2018.
CrossRef
[10] K. Fujimoto, M. Kaneko, K. Matsui, and M. Akutsu, “KBP: Kernel enhancements for low-latency networking for virtual machine and container without application customization,” IEICE Trans. Commun., vol.E105-B, no.5, pp.522–532, May 2022.
CrossRef
[11] X. Zhan, R. Azimi, S. Kanev, D. Brooks, and S. Reda, “CARB: A C-state power management arbiter for latency-critical workloads,” IEEE Comput. Arch. Lett., vol.16, no.1, pp.6–9, 2017.
CrossRef
[12] IEEE Std, “Standard for information technology ― Portable operating system interface (POSIX),” 1003.1, 2001.
[13] The Linux Kernel Organization, “Kernel livepatch,” https://www.kernel.org/doc/Documentation/livepatch/livepatch.txt
URL
[14] J.H. Salim, “When NAPI comes to town,” Linux Conference, 2005.
[15] Intel Corp., “DPDK: Data plane development kit,” http://dpdk.org/, 2014.
URL
[16] Intel Corp., “L3 forwarding with power management sample application,” https://doc.dpdk.org/guides/sample_app_ug/l3_forward_power_man.html
URL
[17] X. Li, W. Cheng, T. Zhang, F. Ren, and B. Yang, “Towards power efficient high performance packet I/O,” IEEE Trans. Parallel Distrib. Syst., vol.31, no.4, pp.981–996, 2020.
CrossRef
[18] J. Cummings and E. Tamir, “Open source kernel enhancements for low latency sockets using busy poll,” Intel White Paper, 2013.
[19] T. Høiland-Jørgensen, J.D. Brouer, D. Borkmann, J. Fastabend, T. Herbert, D. Ahern, and D. Miller, “The eXpress data path: Fast programmable packet processing in the operating system kernel,” Proc. 14th International Conference on emerging Networking EXperiments and Technologies (CoNEXT), pp.54–66, 2018.
CrossRef
[20] A. Belay, G. Prekas, M. Primorac, A. Klimovic, S. Grossman, C. Kozyrakis, and E. Bugnion, “IX: A protected dataplane operating system for high throughput and low latency,” 11th USENIX Symposium on Operating Systems Design and Implementation (OSDI), pp.49–65, 2014.
[21] G. Prekas, M. Kogias, and E. Bugnion, “ZygOS: Achieving low tail latency for microsecond-scale networked tasks,” 26th ACM Symposium on Operating Systems Principles (SOSP), pp.325–341, 2017.
CrossRef
[22] A. Ousterhout, J. Fried, J. Behrens, A. Belay, and H. Balakrishnan, “Shenango: Achieving high CPU efficiency for latency-sensitive datacenter workloads,” 16th USENIX Symposium on Networked Systems Design and Implementation (NSDI), 2019.
[23] K. Kaffes, T. Chong, J.T. Humphries, D. Mazières, C. Kozyrakis, A. Belay, and D. Mazì Eres, “Shinjuku: Preemptive scheduling for μ second-scale tail latency,” 16th USENIX Symposium on Networked Systems Design and Implementation (NSDI), 2019.
[24] Huaweii, “DMM lwIP,” https://github.com/Huawei/DMM 2018.
URL
[25] D. Zhuo, K. Zhang, Y. Zhu, H. Harry Liu, M. Rockett, A. Krishnamurthy, and T. Anderson, “Slim: OS kernel support for a low-overhead container overlay network slim: OS kernel support for a low-overhead container overlay network,” 16th USENIX Symposium on Networked Systems Design and Implementation (NSDI), pp.331–344, 2019.
[26] D. Brodowski, “Linux CPUFreq governor,” https://www.kernel.org/doc/Documentation/cpu-freq/governors.txt
URL
[27] Kubernetes, https://kubernetes.io
URL
[28] K.N. Khan, M. Hirki, T. Niemi, J.K. Nurminen, and Z. Ou, “RAPL in action: Experiences in using RAPL for power measurements,” ACM Trans. Model. Perform. Eval. Comput. Syst., vol.3, no.2, pp.1–26, March 2018.
CrossRef
[29] R. Kavanagh, D. Armstrong, and K. Djemame, “Accuracy of energy model calibration with IPMI,” 2016 IEEE 9th International Conference on Cloud Computing (CLOUD), pp.648–655, 2016.
CrossRef
[30] S. Bradner and J. McQuaid, “RFC 2544: Benchmarking methodology for network interconnect devices,” IETF, 1999.
CrossRef
[31] Intel Corp., “Pktgen-DPDK,” https://github.com/pktgen/Pktgen-DPDK
URL