O cache é o rei do desempenho: os processadores precisam de um quarto nível de cache



A diferença entre a velocidade dos processadores no sentido geral e a velocidade da DRAM principal, também no sentido geral, tem sido um problema nos últimos 30 anos - durante esse período, a diferença começou a realmente crescer. E vale a pena dizer honestamente que os engenheiros que desenvolveram o equipamento e os programas que criaram a hierarquia de cache e o software que poderiam tirar proveito disso foram brilhantes. Essa é uma das arquiteturas mais difíceis já concebidas pelo homem.

No entanto, agora que estamos à beira do surgimento de uma hierarquia cada vez maior de memória, quando a memória não volátil, como o Optane 3D XPoint (uma variante de memória com alteração de fase) nos formatos DIMM e SSD, começa a aparecer, bem como novos protocolos (CXL, OpenCAPI, CCIX, NVLink e Gen-Z), surge a pergunta: é hora de adicionar um cache de quarto nível aos servidores? Como o trabalho de um número tão grande de dispositivos depende do complexo da CPU - alguns estão mais próximos e outros mais distantes - é lógico pensar se precisamos de outro nível de cache que oculte os atrasos desses outros tipos de memória e aumente a taxa de transferência de todo o sistema.

Para apresentar as oportunidades, vasculhamos nossa própria memória e, ao mesmo tempo, conversamos com desenvolvedores de arquitetura de chips da IBM, Intel, AMD e Marvell para entender o que eles pensam sobre o uso do cache L4 nos servidores. O cache L4, é claro, não é uma palavra nova em velocidade, mas não é tão comum em arquiteturas de sistema.

No entanto, antes de analisarmos a história do problema.

A adição de um cache de primeiro nível aos processadores que tinham apenas um núcleo no momento foi um comprometimento na década de 1980 que adicionou latência aos subsistemas de memória e reduziu a latência média das solicitações e instruções de dados dos processadores. Os caches L1 estavam originalmente localizados na SRAM externa localizada nas placas-mãe e conectadas ao complexo de memória da CPU. Esse cache L1 estava muito próximo do processador, tanto em termos de frequência de clock quanto em termos de espaço físico na placa, e tornou possível aumentar a carga da CPU. Em seguida, esses caches foram divididos para que os dados usados ​​com freqüência pudessem ser armazenados em um bloco, e as instruções populares no segundo, e esse desempenho aumentou ligeiramente. Em algum momento do aumento da velocidade do clock do processador e da diferença correspondente na velocidade da CPU e DRAM, foram adicionados caches L2 mais gordos, mas também mais lentos (mas mais baratos em termos de largura de banda), novamente no início eles estavam fora do gabinete da CPU, mas então integrado a ele. E quando mais e mais núcleos começaram a ser adicionados à CPU, assim como mais e mais controladores DRAM para carregá-los, blocos de cache L3 ainda maiores foram adicionados à hierarquia.

Na maior parte, esse sistema funcionou muito bem. Em alguns circuitos da CPU, vemos até algumas regras práticas que refletem os níveis da hierarquia de cache, o que nos permitirá estimar as possibilidades associadas ao quarto nível.

Chris Gianos, engenheiro de chips e arquiteto da Intel que liderou o desenvolvimento de muitas gerações passadas de processadores Xeon, explica o seguinte: “Com cada nível de cache, geralmente precisamos crescer o suficiente em relação ao nível anterior para fazer tudo isso valer a pena, porque para obter um aumento notável no desempenho do sistema, é necessário obter uma frequência bastante interessante de chamadas bem-sucedidas. Se você "cair" em dados armazenados em cache em apenas alguns por cento dos casos, será difícil perceber. Tudo o mais diminui sua velocidade, e esse aumento será imperceptível. Portanto, são necessários caches relativamente grandes e, quando se trata de níveis mais altos, são necessários caches realmente grandes. Hoje, L2 é medido em megabytes, L3 é medido em dezenas ou centenas de megabytes. Portanto, fica claro que, se você começar a pensar no cache L4, falaremos sobre centenas de megabytes, se não gigabytes. E esse tamanho definitivamente levará ao seu alto custo. É necessário que existam certas condições, para que essa opção se torne interessante e certamente não será barata. ”

Os engenheiros da AMD que entrevistamos desejavam permanecer anônimos porque não queriam dar a impressão de que a empresa iria adicionar o cache L4 à linha de processadores Epyc - e, para ser mais preciso, a AMD não prometeu nada disso. Entretanto, a empresa reconhece que este é o próximo passo óbvio a considerar e, assim como a Intel, acredita que todos os engenheiros estão pensando em implementar o cache L4. Em essência, a AMD diz que as compensações associadas aos níveis e latências de cache foram extensivamente estudadas tanto na indústria quanto na academia, e que a cada novo nível maior e mais lento que o anterior, existe uma compensação no aumento do caminho geral para a DRAM. Isso também é indicado pela Intel Gianos, falando sobre a necessidade de encontrar um equilíbrio entre solicitações de cache bem-sucedidas e seu volume.

A IBM, é claro, adicionou cache L4 a alguns de seus chipsets X86 nos anos 2000 e, nos anos 2010, adicionou L4 aos chipsets NUMA ( acesso desigual à memória ) nos mainframes do System z11. O processador z11 possui quatro núcleos, cache L1 de 64 KB para obter instruções e cache L1 de 128 KB para dados, além de cache L2 de 1,5 MB para cada núcleo e cache compartilhado L3 de 24 MB para todos os núcleos. O chipset NUMA para z10 tinha dois bancos de 96 MB de cache L4, ou seja, 192 MB no total. Com o lançamento do z12, a IBM reduziu o tamanho do cache L1 para 98 KB por núcleo, mas aumentou o cache L2 para 2 MB por núcleo, dividindo-o em duas partes, para instruções e dados, como no caso de L1. Ela também dobrou o tamanho do cache L3 para 48 MB em seis núcleos, e o tamanho do cache L4 foi aumentado para 384 MB para um par de chips no chipset. À medida que as gerações de processadores System z mudam, os tamanhos de cache aumentam e, para os processadores z15 anunciados em setembro, um par de caches L1 pesará 128 KB cada, um par de caches L2 pesará 4 MB cada e um cache L3 compartilhado para 256 núcleos terá capacidade de 256 MB. O cache L4 em cada compartimento de mainframe é de 960 MB e seu volume total para todo o sistema, que consiste em cinco compartimentos, é de 4,68 GB.

Como mencionamos anteriormente , os processadores Power8 e Power9 têm buffer de memória e a IBM adicionou cache de 16 MB L4 a cada buffer do Centaur, que é cache de 128 MB L4 por soquete para 32 slots de memória. As máquinas Power9 mais baratas não possuem um buffer de memória e, portanto, nenhum cache L4. Os arquitetos que desenvolveram o circuito Power10 estavam ocupados desenvolvendo o circuito para o Power11 e, portanto, não puderam responder nossas perguntas, mas William Stark, que gerenciou o desenvolvimento do Power10, encontrou um pouco de tempo para nós e observou o seguinte:

"Em geral, chegamos à conclusão de que caches de alto nível do último nível são úteis para aumentar a velocidade dos sistemas industriais", explicou Stark, por email. "A alta latência associada à memória não volátil, em particular à memória de estado de fase, gera uma solicitação de cache - possivelmente para um cache do tipo L4 - na hierarquia da memória de armazenamento".

Isso é exatamente o que pensamos. E, a propósito, não afirmamos que o cache L4 esteja necessariamente próximo da memória buffer do futuro DDR5 DIMM. Talvez seja melhor colocá-lo entre o cache do processador PCI-Express e L3 e, melhor ainda, nos buffers de memória e entre o cache do processador PCI-Express e L3. Talvez tenha que ser colocado em cima do controlador de E / S e da memória na futura arquitetura do servidor, que é um pouco como a tecnologia Foveros da Intel .

É possível analisar isso de um ponto de vista diferente - por exemplo, a IBM teve a oportunidade de alterar o tamanho do cristal e os engenheiros decidiram adicionar o cache L4 ao barramento System z NUMA ou ao chip de buffer de memória Power8 e Power9, não por si só, mas simplesmente porque eles ainda tiveram a oportunidade de adicionar transistores depois que todas as funções necessárias foram implementadas. Às vezes, parece-nos que o número de núcleos nos processadores Intel X86 depende do tamanho do cache L3 que eles podem pagar. Às vezes, parece que a Intel atribui o tamanho máximo do cache L3 a um cristal e, depois disso, cristais Xeon de três tamanhos diferentes são simplesmente feitos de acordo com essas especificações - nas últimas gerações eles têm 10, 18 ou 28 núcleos em um processo de fabricação de 14 nm.

Tudo isso, é claro, são questões puramente acadêmicas, mas elas nos dão a motivação potencial para a IBM e outros fabricantes de chipsets adicionarem o cache L4. Isso não apenas pode ajudar em alguns casos, mas é uma coisa bastante óbvia. Acreditamos que em um monstro de E / S como o mainframe System z, o cache L4 está em seu lugar sem perguntas e beneficia todos os clientes, aumentando a taxa de transferência dessas máquinas e permitindo que trabalhem com 98-99% da carga do processador, desde quantos núcleos , e a escala do NUMA nos mainframes aumentou muito recentemente.

Não há razão para fazer o cache L4 exclusivamente na DRAM interna (como a IBM faz com seus chips) ou com base em uma SRAM muito mais cara - é disso que Rabin Sugumar, arquiteto de chips da Cray Research, Sun Microsystems, Oracle, Broadcom nos lembra. , Cavium e Marvell:

"Nossos caches L3 já são grandes o suficiente", diz Sugumar. - Então o L4, no caso de seu interesse, precisa ser feito usando uma tecnologia diferente. Talvez eDRAM ou mesmo HBM ou DRAM. Nesse contexto, uma implementação do cache L4 baseado no HBM parece uma opção interessante, e esse cache não resolve tanto o problema de latência quanto a largura de banda. Como a capacidade da HBM é limitada e a largura de banda é grande, podemos obter um certo aumento de velocidade - e em alguns casos especiais, realmente vemos um aumento significativo na largura de banda ". Sugumar acrescenta que, para um número bastante grande de aplicativos, é observado um número relativamente grande de falhas de cache. No entanto, você precisa calcular se a adição do próximo nível de cache valerá a pena.

Outro caso de uso possível para algo como o cache L4, diz Sugumar, é usar a DRAM local como cache. “Nós não realizamos nenhum desses estudos em laboratório, mas suponhamos que tenhamos uma interface de alta largura de banda no chip, conectada a uma memória compartilhada em algum lugar do outro lado do loop, a uma distância de 500 ns a 1 μs. Um dos casos de uso será criar um cache que mova esses dados da memória compartilhada para a DRAM local. Você pode imaginar o trabalho da máquina de estado gerenciando essa memória; portanto, na maioria das vezes, as chamadas serão direcionadas para a DRAM local e você pode minimizar o número de chamadas para a DRAM distribuída geral ".

Esta opção nos parece um tipo muito interessante de NUMA. A propósito, Sugumar estava trabalhando na memória distribuída para sistemas paralelos de alta velocidade na Sun Microsystems, mesmo antes do surgimento da memória não volátil. E um dos problemas com essas diferentes variantes da hierarquia de memória era que, se uma delas se perder devido a uma falha na rede ou no barramento, a máquina inteira falhará. "Nos sistemas de memória distribuída, as falhas de rede precisam ser tratadas com mais elegância, e isso causa muitos desafios de design".

Outro ponto é que queremos que qualquer cache de alto nível, nem mesmo o L4, seja realizado ao máximo com a ajuda do ferro e com o mínimo com a ajuda do software. Os kernels do sistema operacional e outros softwares sempre precisam de algum tempo para acompanhar o hardware, seja adicionando novos kernels ou caches L3 ou L4 ou memória não volátil endereçável.

"Em algum momento, um nível extra de cache se tornará inevitável", diz Gianos. - Chegamos ao primeiro nível de cache e, em algum momento, o segundo apareceu. E então finalmente adicionamos um terceiro. E um dia teremos um quarto. A única questão é quando e por quê. E parece-me que suas observações sobre os recursos desse cache são bastante interessantes. Mas a Intel ainda não decidiu quando ou por que essas coisas serão tornadas públicas. Outras empresas também estão estudando esse problema; seria tolice não examiná-lo. Cedo ou tarde isso acontecerá, mas logo será, ou não será muito - ainda não está claro. ”

Source: https://habr.com/ru/post/pt485374/


All Articles