Carregando o modo FS com O3CPU multi-core no gem5

Sep 17 2020

Preciso executar o modo FS com 64 núcleos O3.

De acordo com :Como executar uma simulação de sistema completo gem5 arm aarch64 com fs.py com mais de 8 núcleos? Devo usar um destes dois métodos: extensões GICv2 ou GICv3 .

Mas quando eu adiciono o comando:

--param 'system.realview.gic.gem5_extensions = True,

o terminal continua a produzir informações semelhantes às seguintes:

Warn:context 2:1900000 consecutive store conditional failures.

Quando adiciono o comando:

--machine-type VExpress_GEM5_V2,

o terminal emite as seguintes informações:

warn: Gicv3Distributor::write(): setting ARE to 0 is not supported!, e não há mais informações depois disso, parece que ainda está em execução.

Eu li esta lista de discussão: https://www.mail-archive.com/[email protected]/msg18133.html Parece que o multi-O3CPU não é usado para inicializar o sistema Linux no final.

Portanto, devo usar AtomicSimpleCPU para inicializar, estabelecer um ponto de verificação e, em seguida, carregar o ponto de verificação com núcleos fora de ordem? A configuração de inicialização precisa ser semelhante à configuração de tempo de execução?

Respostas

1 CiroSantilli Sep 17 2020 at 13:38

Pelo que posso ver pela sua descrição, não há mensagens de erro que necessariamente impliquem um problema de versão do GIC, temos muitos avisos por padrão e parecem OK.

Mas sim, inicializar múltiplos núcleos com caches (que são exigidos pelo O3) no ARM é geralmente interrompido devido a problemas de acesso não cacheáveis ​​descritos em https://gem5.atlassian.net/browse/GEM5-711 , e fazer um ponto de verificação atômico após a inicialização e restaurar O3 é uma solução para o que foi mencionado nos comentários desse tíquete: https://gem5.atlassian.net/browse/GEM5-711?focusedCommentId=12001 Existe uma chance de você não encontrar esse problema, mas se você conseguir ver facilmente se esse é provavelmente o problema específico ou não com base na mensagem de erro, você tem a mesma falha de declaração que esse problema?

Existe alguma razão pela qual você não deseja verificar e restaurar, já que isso economiza vários minutos do tempo de inicialização? Sim, é compatível e é um dos principais casos de uso de checkpoint: Quais características do sistema, como número de núcleos de configurações de cache, posso alterar ao restaurar um checkpoint no gem5?

Além disso, sempre forneça o comando CLI completo e a saída e a versão do gem5 ao relatar esse tipo de problema. E no caso de travamentos, vale a pena dar uma olhada rápida --debug ExecAlle identificar quais foram as últimas instruções não estranhas sendo executadas, pois isso restringe bastante os possíveis problemas.