Administração do Windows

Dentro do kernel do Windows Vista: Parte 1

Mark Russinovich

Visão geral:

• Agendamento e prioridade do thread
• Links simbólicos baseados em arquivo
• Cancelando operações de E/S

Esta é a primeira parte de uma série sobre as novidades do kernel do Windows Vista. Nesta edição, veremos as alterações nas áreas de processos, threads e E/S. Edições posteriores tratarão de abordar temas como gerenciamento de memória, inicialização e desligamento, confiabilidade e recuperação, além de segurança.

O escopo deste artigo compreende alterações ao kernel do Windows Vista™ apenas, especificamente o Ntoskrnl.exe e os componentes estreitamente relacionados a ele. Lembre-se de que há muitas outras alterações significativas no Windows Vista que ficam de fora do kernel propriamente dito e que, portanto, não serão abordadas. Isso inclui aprimoramentos ao shell (exemplo: pesquisa de área de trabalho integrada), sistema de rede (como a nova pilha do IPv6 e o firewall bidirecional) e o modelo gráfico de última geração (como o Aero™ Glass, o Windows® Presentation Foundation, o Gerenciador de Janelas da Área de Trabalho e o novo modelo de driver gráfico). Também não são abordadas as novas UMDF e KMDF (Estruturas de Driver do Modo de Usuário do Windows e do Modo Kernel), pois elas são instaláveis em níveis anteriores de versões anteriores do Windows.

Contagem de ciclos da CPU

O Windows Vista inclui vários aprimoramentos na área de processos e threads, que incluem o uso do contador de ciclos da CPU, para obter uma alocação de CPU mais parcial, e o novo MMCSS (Multimedia Class Scheduler Service), que auxilia os aplicativos de mídia a oferecer uma reprodução sem problemas.

Todas as versões do Windows NT® até e incluindo o Windows Vista programam uma rotina de interrupção do timer do intervalo para execução a cada 10 ou 15 ms (milissegundos), aproximadamente, dependendo da plataforma de hardware. A rotina analisa em que thread ocorreu interrupção e atualiza a estatística de uso da CPU do thread como se esse thread tivesse sido executado no intervalo inteiro, quando, na realidade, o thread pode ter iniciado a execução um pouco antes do fim do intervalo. Além disso, o thread poderia ter sido atribuído pela CPU tecnicamente, mas não teve a chance de ser executado porque rotinas de interrupção de hardware e software foram executadas no lugar.

Embora a contabilização de tempo com base no clock possa servir para ferramentas de diagnostico que geram relatório de thread e processam o uso da CPU, o uso desse método pelo agendador de thread pode ocasionar uma alocação parcial de CPU. Por padrão, em versões clientes do Windows, os threads têm permissão para executar até 2 marcações do clock (6 se estiver em primeiro plano). Entretanto, o thread pode não obter quase nenhum tempo na CPU ou até 6 marcações (18 se estiver em primeiro plano), dependendo do próprio comportamento e de outras atividades no sistema.

A Figura 1 mostra a parcialidade que pode ocorrer quando dois threads com a mesma prioridade ficam prontos para execução ao mesmo tempo. O thread A é executado até o próximo vencimento de intervalo de fração de tempo, quando o agendador supõe que ele tenha ficado em execução pelo intervalo inteiro e, então, decide que o giro do thread A foi concluído. Além disso, o Thread A fica não parcialmente carregado devido à interrupção ocorrida durante o seu giro. No intervalo seguinte, o agendador seleciona o Thread B para assumir e ele é executado em um intervalo inteiro.

Figura 1** Agendamento de thread parcial **

No Windows Vista, o agendador usa o Registro do contador de ciclos de processadores modernos para rastrear, de maneira precisa, quantos ciclos de CPU um thread pode executar. Estimando-se quantos ciclos a CPU pode executar em um intervalo de clock, ele pode distribuir de modo mais preciso os giros na CPU. Além disso, o agendador do Windows Vista não conta a execução de interrupção em relação ao giro do thread. Isso significa que, no Windows Vista, um thread obterá sempre pelo menos o próprio giro na CPU, e nunca mais de um intervalo de clock extra de execução, o que resulta em maior igualdade e mais comportamento determinístico do aplicativo. A Figura 2 mostra como o Windows Vista responde ao cenário mostrado na Figura 1, concedendo aos dois threads pelo menos um intervalo de execução.

Figura 2** Agendamento com base em ciclos do Windows Vista **

A barra lateral "Watching Process CPU Usage" ilustra como você pode monitorar o processo de uso do ciclo da CPU para si mesmo, por meio do utilitário Process Explorer.

Multimedia Class Scheduler Service

O usuário espera que aplicativos de multimídia, incluindo players de música e de vídeo, propiciem uma experiência de reprodução contínua. Contudo, a demanda pela CPU por parte de outros aplicativos em execução simultaneamente, como antivírus, indexação de conteúdo ou mesmo o cliente de email, pode resultar em contratempos indesejáveis. Para oferecer uma experiência de reprodução melhor, o Windows Vista apresenta o MMCSS, que gerencia as prioridades da CPU de threads multimídia.

Um aplicativo de multimídia como o Windows Media® Player 11 é registrado com o MMCSS por meio de novas APIs que indicam as respectivas características de multimídia, que devem corresponder a uma das listadas por nome na seguinte chave do Registro:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\Currentversion\Multimedia\SystemProfile\Tasks

Figura A** Exibindo o tempo de CPU e Ciclos Delta no Process Explorer **(Clique na imagem para aumentar a exibição)

Figura 3** Definição de tarefa de áudio do Multimedia Class Scheduler **(Clique na imagem para aumentar a exibição)

O MMCSS, implementado em %SystemRoot%\System32\Mmcss.dll e executado em um processo de Host de serviço (Svchost.exe), tem um thread de gerenciamento de prioridade que é executado na prioridade 27. (As prioridades do thread no Windows vão de 0 a 31.) Esse thread aumenta a prioridade de threads de multimídia registrados no intervalo associado ao valor Categoria de Agendamento da respectiva chave do Registro da tarefa, conforme listado na Figura 4. No Windows, prioridades do thread 16 e superiores estão no intervalo de prioridade em tempo real e são superiores a todos os demais threads no sistema (com exceção dos threads de trabalho do Gerenciador de memória do kernel, executado nas prioridades 28 e 29). Somente contas administrativas, como a conta Sistema Local em que o MMCSS é executado, têm o privilégio Aumentar Prioridade, requerido para definir prioridades do thread em tempo real.

Figure 4 Prioridades do thread do MMCSS

Ao reproduzir um arquivo de áudio, o Windows Media Player registra threads da tarefa de Áudio; ao reproduzir um vídeo, ele registra threads da tarefa de Reprodução. O serviço MMCSS aumenta todos os threads que indicaram estar fornecendo um fluxo ao mesmo tempo em que são executados no processo que pertence à janela do primeiro plano e quando têm o valor BackgroundOnly definido para Verdadeiro na respectiva chave de definição da tarefa.

Mas, embora o MMCSS auxilie threads multimídia a obter o tempo de CPU que desejem, ele também deseja garantir que outros threads obtenham pelo menos algum tempo de CPU, para que o sistema e outros aplicativos permaneçam responsivos. O MMCSS, portanto, reserva um percentual de tempo de CPU para outra atividade, especificada no valor do Registro seguinte:

HKLM\Software\Microsoft\Windows NT\Currentversion\Multimedia\SystemProfile\SystemResponsiveness 

Por padrão, esse percentual é 20%; o MMCSS monitora o uso da CPU para garantir que threads multimídia não serão aumentados mais de 8 ms em um período de 10 ms caso outros threads precisem da CPU. Para que os threads multimídia fiquem fora do caminho pelos 2 ms restantes, o agendador suspende as prioridades desses threads no intervalo de 1 a 7.

Veja como o MMCSS aumenta a prioridade do thread, lendo na barra lateral "Watching MMCSS Priority Boosting".

Links simbólicos baseados em arquivo

As alterações relacionadas a E/S no Windows Vista incluem links simbólicos baseados em arquivo, processamento de conclusão de E/S mais eficiente, suporte abrangente de cancelamento de E/S e E/S priorizada.

Um recurso do sistema de arquivos que muitos consideraram ausente do NTFS, o link de arquivo simbólico (ou, como é chamado no UNIX, soft link), chega finalmente ao Windows Vista. A versão Windows 2000 do NTFS introduziu links de diretório simbólicos, chamados de junções de diretório, que permitem criar um diretório que aponta para um diretório diferente; no entanto, até a versão do Windows Vista, o NTFS só oferecia suporte a links físicos para arquivos.

Uma diferença importante no modo como o Windows resolve links simbólicos e junções de diretório é onde o processamento ocorre. O Windows processa links simbólicos no sistema local, mesmo quando eles fazem referência a um local em um servidor de arquivos remoto. O Windows processa junções de diretório que fazem referência a um servidor de arquivos remoto no próprio servidor. Links simbólicos em um servidor podem, portanto, fazer referência a locais acessíveis apenas no cliente, como outros volumes de cliente, ao passo que as junções de diretório não são capazes disso. Para lidar com isso, o Windows Vista oferece suporte ao novo tipo de link simbólico tanto para arquivos quanto para diretórios.

Muitos comandos do sistema de arquivos foram atualizados para compreender as implicações de links simbólicos. Por exemplo, o comando Excluir não sabe seguir links, o que resultaria na exclusão do destino, mas sabe excluir o link, por outro lado. Contudo, como nem todos os aplicativos podem manipular links simbólicos corretamente, criar um link simbólico requer o novo privilégio Criar Link Simbólico, que, por padrão, só os administradores têm.

Você pode criar um link simbólico em um prompt de comando, usando o comando Mklink. O comando de diretório interno do prompt de comando identifica um link simbólico sinalizando-o com <SYMLINK> e mostrando o destino entre colchetes, como mostra a Figura 5. O Windows Explorer também reconhece links simbólicos e os mostra por meio da seta de atalho. Você pode ver o destino de um link no Explorer adicionando a coluna Destino do Link à janela de navegação.Watching MMCSS Priority Boosting

Você pode observar o aumento de thread que o serviço MMCSS aplica aos threads do Windows Media Player, reproduzindo um clipe de vídeo ou de áudio, executando o Monitor de Desempenho, configurando a escala de gráfico para 31 (a prioridade do thread mais alta do Windows) e adicionando o contador Prioridade atual de todas as instâncias dos objetos de thread do Media Player (Wmplayer.exe) à exibição. Um ou mais threads serão executados na prioridade 21.

Figura B** Aumento de prioridade do thread do Windows Media Player **(Clique na imagem para aumentar a exibição)

Figura 5** Usando o Mklink para criar um link simbólico **(Clique na imagem para aumentar a exibição)

Conclusão e cancelamento de E/S

Existem várias alterações de escopo ao sistema de E/S que podem melhorar o desempenho de aplicativos de servidor. Esses aplicativos geralmente usam um objeto de sincronização chamado porta de conclusão, para aguardar a conclusão de solicitações de E/S assíncronas. Antes do Windows Vista, quando essa E/S era concluída, o thread que emitiu a E/S executaria o trabalho de conclusão de E/S, ocasionando uma alternância no processo a que pertence o thread e interrompendo tudo o mais que estivesse acontecendo. O sistema de E/S, então, atualizaria o status da porta de conclusão para despertar um thread que estivesse à espera da alteração desse status.

No Windows Vista, o processo de conclusão de E/S é executado não necessariamente pelo thread que emitiu a E/S, mas pelo que está à espera da porta de conclusão para despertar. Essa alteração relativamente pequena evita o agendamento desnecessário do thread e de alternâncias de contexto que podem degradar o desempenho geral do aplicativo e do sistema. Para melhorar ainda mais o desempenho, um servidor pode recuperar os resultados de várias operações de E/S de uma conclusão em uma solicitação, evitando transações no modo kernel.

Provavelmente, a alteração mais visível no sistema de E/S da perspectiva de um usuário final é o suporte do Windows Vista para cancelamento de operações de E/S assíncronas. Se você já executou um comando net view ou tentou acessar um compartilhamento em um sistema remoto offline no Windows XP ou no Windows Server® 2003, já teve problemas com operações de I/O que não pudessem ser canceladas: o comando ou navegador de arquivos não responde até que o tempo limite da rede expire. O aplicativo não tem escolha, a não ser aguardar até a falha da operação, porque não há para ele um modo de informar ao driver de dispositivo que está executando a E/S que ele não se importa mais com a E/S.

No Windows Vista a maioria das operações de E/S podem ser canceladas, incluindo a operação open file I/O que o Net View e o Explorer utilizam. No entanto, aplicativos têm que ser atualizados para responder a solicitações do usuário final quanto ao cancelamento da E/S, e vários utilitários do Windows Vista que interagem com dispositivos que têm tempo limite contam com o suporte necessário. As caixas de diálogo abrir arquivo e salvar, usadas por quase todo aplicativo do Windows, incluindo aplicativos de terceiros, por exemplo, agora habilitam o botão Cancelar enquanto tentam exibir o conteúdo de uma pasta. O comando Net também cancela a respectiva E/S síncrona quando Ctrl+C é pressionado.

Você pode conferir os benefícios do cancelamento de E/S abrindo um prompt de comando no Windows Vista e digitando:

net view (\\nonexistentmachine)

O comando hesitará enquanto o Windows tenta contatar o sistema não existente, mas você pode digitar Ctrl+C para encerrá-lo. No Windows XP, digitar Ctrl+C não tem nenhum efeito e o comando não retorna até que a operação de rede atinja o tempo limite.

Outro tipo de E/S que causou problemas ao usuário em versões passadas do Windows são as E/Ss que drivers de dispositivos não cancelavam corretamente, porque não havia nenhum modo fácil de os drivers saberem que deveriam fazê-lo. Se você já encerrou um processo, e, em seguida, viu-o demorando-se em ferramentas de exibição do processo, então você testemunhou um driver de dispositivo falhando em responder a um encerramento de processo e cancelando a E/S emitida pelo processo que não havia sido concluído. O Windows não é capaz de executar a limpeza de processo final até que a E/S do processo termine ou seja cancelada. No Windows Vista, drivers de dispositivo registram-se facilmente para a notificação de finalizações do processo; assim, chega ao fim a maioria dos problemas dos processos sem solução.

Prioridade de E/S

Embora o Windows sempre tenha dado suporte à priorização de uso da CPU, esse recurso não foi incluído no conceito de prioridade de E/S. Sem a prioridade de E/S, atividades de segundo plano como indexação de pesquisa, verificação de vírus e desfragmentação de disco podem causar impactos graves à agilidade de respostas de operações de primeiro plano. Um usuário que abra um aplicativo ou um documento enquanto outro processo executa E/S de disco, por exemplo, experimentará atrasos, pois a tarefa de primeiro plano aguarda o acesso ao disco. A mesma interferência também afeta a reprodução do fluxo contínuo de conteúdo multimídia, como música, em um disco rígido.

O Windows Vista introduz dois tipos de priorização de E/S para ajudar a fazer com que as operações de E/S em primeiro plano tenham a preferência: prioridade em operações de E/S individuais e reservas combinadas de largura de banda de E/S. O sistema de E/S do Windows Vista inclui suporte interno para cinco prioridades de E/S, como mostra a Figura 6, mas apenas 4 prioridades são usadas (versões futuras do Windows poderão oferecer suporte à prioridade Alta).

Figure 6 Prioridades de E/S do Windows Vista

A E/S tem uma prioridade padrão Média e o Gerenciador de Memória utiliza a Crítica, quando quer gravar os dados “sujos” de memória fora do disco em situações de memória baixa, a título de liberar espaço na RAM para outros dados e códigos. O Agendador de Tarefas do Windows define a prioridade de E/S para Baixa nas tarefas que têm a prioridade de tarefa padrão; já a prioridade especificada por aplicativos gravados do Windows Vista que executam o processamento do segundo plano é Muito Baixa. Todas as operações de segundo plano do Windows Vista, incluindo verificação do Windows Defender e indexação de pesquisa de área de trabalho, utilizam prioridade de E/S Muito Baixa.Analisando a prioridade muito baixa de E/S

O Process Monitor, um sistema de arquivos em tempo real e utilitário de monitoramento do Registro, da Sysinternals, coleta informações detalhadas para operações de gravação e leitura do sistema de arquivos, incluindo as respectivas prioridades de E/S no Windows Vista. A linha realçada mostra o exemplo de uma E/S de prioridade muito baixa, emitida pelo SuperFetch (que discutirei em minha próxima edição).

Figura C** Exibindo a prioridade muito baixa de E/S no Process Monitor **(Clique na imagem para aumentar a exibição)

O driver de dispositivo de classe de armazenamento do sistema (%SystemRoot%\System32\Classpnp.sys) impõe as prioridades de E/S e elas são aplicadas automaticamente à E/S direcionada à maioria dos dispositivos de armazenamento. A classe e os demais drivers de armazenamento inserem E/Ss Médias à frente das Baixas e Muito Baixas nas respectivas filas, mas emitem pelo menos uma E/S Baixa ou Muito Baixa em espera a cada segundo, para que processos em segundo plano possam avançar. Dados lidos por E/S Muito Baixa também fazem com que o Gerenciador de Cache grave modificações imediatamente no disco, em vez de fazê-lo posteriormente, e desvie a respectiva lógica read-ahead para operações de leitura que, do contrário, lêem preemptivamente do arquivo que está sendo acessado. Dê uma olhada na barra lateral "Seeing Very Low I/O Priority" para ter um exemplo de prioridade de E/S Muito Baixa usando o utilitário Process Monitor.

O suporte da reserva de largura de banda do Windows Vista é útil para aplicativos Media Player, e o Windows Media o utiliza, juntamente com aumentos de prioridade, para propiciar reprodução de conteúdo local praticamente sem falhas. Um aplicativo Media Player solicita ao sistema de E/S para lhe garantir a capacidade de ler dados a uma taxa especificada e, se o dispositivo puder fornecer os dados na taxa solicitada e as reservas existentes o permitirem, ele fornecerá ao aplicativo orientação sobre a velocidade em que ele deverá emitir E/Ss e o tamanho dessas E/Ss. O sistema de E/S não prestará serviço a demais E/Ss, a menos que possa atender aos requisitos de aplicativos que fizeram reserva no dispositivo de armazenamento de destino.

Uma alteração final do sistema de E/S que vale a pena mencionar relaciona-se ao tamanho das operações de E/S. Desde a primeira versão do Windows NT, o Gerenciador de Memória e o sistema de E/S limitaram a 64KB o volume de dados processados por uma solicitação de E/S de armazenamento individual. Portanto, ainda que um aplicativo emita uma solicitação de E/S muito maior, ela será desmembrada em solicitações individuais com um tamanho máximo de 64KB. Cada E/S gera uma sobrecarga em transições para o modo kernel e ao iniciar uma transferência de E/S no dispositivo de armazenamento; assim, os tamanhos de solicitações de E/S de armazenamento do Windows Vista storage não são mais completados. Vários componentes do modo de usuário do Windows Vista foram modificados para aproveitar o suporte a E/Ss maiores, incluindo a funcionalidade de cópia do Explorer e o comando Copiar do prompt de comando, que agora emite E/Ss de 1 MB.

A seguir

Você acabou de ver duas áreas nas quais o kernel do Windows Vista foi aprimorado. Você pode esperar informações adicionais detalhadas na próxima edição do meu livro, Windows Internals (em co-autoria com David Solomon), cuja edição está prevista para ocorrer simultaneamente à próxima versão do Windows Server, com o codinome “Longhorn." Em minha próxima edição, continuarei apresentando o novo kernel, discutindo gerenciamento de memória, juntamente com inicialização e desligamento do sistema.

Mark Russinovich é um colega da área técnica da Microsoft na divisão de plataforma e serviços. Ele é co-autor do livro Microsoft Windows Internals (Microsoft Press, 2004) e palestrante assíduo de TI e conferências de desenvolvedores. Russinovich uniu-se à Microsoft com a recente aquisição da empresa de que foi co-fundador, a Winternals Software. Ele criou também a Sysinternals, onde publicou os utilitários Process Explorer, Filemon e Regmon.

© 2008 Microsoft Corporation e CMP Media, LLC. Todos os direitos reservados. A reprodução parcial ou completa sem autorização é proibida..