4.7.5.2 – Implicações para arquitetura baseados no contexto MMU/CACHE.
A idéia inteira por trás do conceito de MMU e facilidades do contexto cache é para permitir muitos ADDRESS SPACES para dividir os recursos CACHE/MMU no CPU.
Para levar total vantagem de tal facilidade, e ainda manter a coerência descrita acima, requer-se algumas considerações extras do implementador.
As questões envolvidas variam muito de uma implementação para outro, pelo menos esta tem sido a experiência do autor. Mas em particular algumas destas questões são provavelmente para ser:
• A relação do mapeamento do espaço Kernel para os USER-SPACE, num contexto são convertidas, alguns mapeamentos do
sistema kernel tem um atributo global, naquele o hardware não concerde ele mesmo com o contexto da informação
quando uma tradução é feita, que tem seu atributo.
Desta forma um FLUSH (em qualquer contexto) de um mapeamento de um Kernel CACHE/MMU poderia ser suficiente.
De qualquer maneira e possível um outros implementações para o Kernel para dividir o contexto chave associado com um ADDRESS SPACE particular. Pode ser necessário em tal caso andar por todos contextos que são contentemente válidos e efetuam o Flush completo em cada um para um Kernall Address Space Flush.
O custo por contexto Flush podem tornar uma questão chave, especialmente com respeito ao TLB. Por exemplo, se um Tlb Flush e necessário, em um grande Range de endereços (ou um inteiro Address Space) pode ser mais prudente distribuir e assumir um nova contexto MMU/para este processo por causa da eficiência
4.7.6 – Como tratar o que a arquitetura flush não executa com exemplos
A arquitetura Flush descrita não faz emendas para coerência de projetos DMA com dados Cached. Isto também não tem provisões para nenhuma estratégia de mapeamento necessários pelo DMA e projetos se forem necessários em um certa máquina Linux é Portad To. Nenhuma destas questões são para a arquitetura Flush.
Tais questões são negociadas mais claramente no nível do Driver do projeto. O autor está mais convencido disto depois de sua experiência com um conjunto comum de sparc device drivers que precisaram de toda função corretamente em mais do que uma hand full de cache/mmu e bus architetures no mesmo kernel.
De fato esta implementação é mais eficiente porque o motorista sabe exatamente quando o DMA precisa ver o dado consistente ou quando o DMA está indo criar uma inconsistência que deve ser resolvida.
Nenhuma tentativa para atingir este nivel de eficiencia via cochetes soma ao codigo de administracao generica da memoria kernel seria complexo e muito obscura como um exemplo, considere no sparc como os DMA buffers são manuscrito.
Quando um device driver deve efetuar o DMA para/de um único buffer, ou uma dispersa lista de muitos buffers, ele usa um conjunto de rotinas abstratas.