Arquitetura entre Sistemas Operativos/Mecanismos de Controlo de Memória e Recursos
Introdução
[editar | editar código-fonte]Os principais métodos utilizados pelos sistemas operativos modernos para controlar a distribuição dos recursos mais relevantes de um computador são normalmente desenvolvidos de forma a satisfazer a maioria das necessidades comuns dos sistemas ou dos utilizadores. No entanto, esses métodos nem sempre são os mais adequados para serem utilizados em situações específicas onde se pode querer um controlo mais sofisticado do uso dos recursos. Mecanismos de controlo de recursos premitem um controlo mais sofisticado.
Limits
[editar | editar código-fonte]O padrão System V e BSD definem um mecanismo para controlar os recursos do sistema. A biblioteca libc implementa esse mecanismo e disponibiliza-o para ser usado em sistemas Unix. As funcções setrlimit e getrlimit permitem respectivamente definir e obter os limites dos recursos que esse mecanismo é capaz de controlar. Com o setrlimit é possível definir dois tipos de limites: o soft e o hard. O primeiro é utilizado como um alerta ao processo que o limite permitido foi atingido. E o último funciona como limite máximo permitido para utilização do recurso, sendo que a partir do momento que é atingido, o sistema toma certas ações de maneira a voltar à normalidade, inclusive eliminar o processo que utiliza os recursos indevidamente. É bom salientar que esses limites são aplicados exclusivamente por sessão de utilizador e não por processo. Os recursos controlados por esse mecanismo são:
• RLIMIT_CPU (processador): especifica o limite máximo em segundos em que um processo pode utilizar o processador. Quando o processo atinge o limite soft um sinal de término é enviado ao processo. Se o processo ainda não estiver terminado quando o limite hard for atingido o processo será eliminado;
• RLIMIT_CORE (tamanho do ficheiro de core): ajusta o tamanho máximo do ficheiro de core. Quando o seu valor é 0, o ficheiro de core não é criado;
• RLIMIT_DATA (segmento de dados): limita o tamanho máximo do segmento de dados em memória utilizados pelos processos;
• RLIMIT_LOCKS (número de ficheiros bloqueados): define o limite máximo de ficheiros que podem ser bloqueados ao mesmo tempo através das funções flock() e fcntl();
• RLIMIT_MEMLOCK (bytes alojados pelo utilizador na memória física): permite especificar a quantidade de bytes que ficarão na memória física e não serão colocados na memória virtual;
• RLIMIT_FSIZE (tamanho dos ficheiros): limita o tamanho máximo dos ficheiros que podem ser criados pelos processos;
• RLIMIT_NOFILE (número de ficheiros): limita o máximo de descritores de ficheiros que podem ser abertos pelos processos;
• RLIMIT_NPROC (número de processos): ajusta o número máximo de processos simultâneos de um utilizador;
• RLIMIT_RSS (páginas na memória): limita o máximo de páginas que um processo pode manter residente na memória física;
• RLIMIT_STACK (tamanho da pilha): especifica o tamanho máximo da pilha de cada processo.
Mais detalhes podem ser encontrados no Manual do Programador Linux.
Pode-se notar que esse mecanismo permite definir somente o limite máximo de utilização dos recursos, não permitindo garantir limites mínimos de uso. Além disso, são definidas por sessão de utilizador e não são alteráveis durante a vida dos processos.
Class-Based Kernel Resource Management — CKRM
[editar | editar código-fonte]O CKRM é um controlador de recursos orientado a objetivos que visa fornecer serviços diferenciados a classes de tarefas para todos os recursos que ele pode controlar.
Uma classe é definida como um grupo dinâmico de objetos do sistema operacional de um tipo específico, como processos e threads. As classes possuem compartilhamentos associados aos recursos do sistema, que são definidos pelo administrador do sistema. Cada classe obtém compartilhamentos separados para tempo de CPU, páginas de memória, banda de disco e banda de rede. O escalonador do recurso tenta da melhor forma possível respeitar os limites dos compartilhamentos da classe.
Por exemplo, uma classe A com um compartilhamento de 50% de tempo de CPU, coletivamente obtém 50% do uso do processador, ou seja, para todos os processos da classe.
O CKRM é dividido em vários componentes:
• Core: define as entidades básicas usadas pelo CKRM, como as classes e os eventos, e atua como elo de ligação entre todos os outros componentes;
• Método de classificação: é um componente opcional e ajuda na associação automática dos objetos do núcleo às classes do seu tipo. Atualmente existem dois tipos de classe: de tarefas e de sockets, para o agrupamento de processos e sockets respectivamente.
• RCFS (sistema de ficheiros de controlo de recursos): provê uma interface de criação e manipulação das classes baseado em diretórios e ficheiros. A comunicação entre o utilizador e núcleo é feita através de leituras e escritas em ficheiros nos diretórios do sistema de ficheiros. Os diretórios do RCFS corresponde às classes.
• Controladores de recursos: são os reguladores de utilização dos recursos. São implementações independentes e estão interessadas somente no controlo de um recurso específico, ou seja, existe um controlador para cada recurso que se deseja controlar.
O fato de ser dividido em módulos permite que pessoas interessadas em construir um novo controlador para algum recurso possam utilizar a estrutura fornecida pelo CKRM, diminuindo consideravelmente o tempo de desenvolvimento.
O CKRM também permite um melhor mensuramento do uso do sistema. Atualmente é difícil atribuir os recursos consumidos em kernel mode a uma determinada tarefa. Com uma medida mais acurada do consumo dos recursos, o administrador do sistema pode decidir mais precisamente no controlo de uma aplicação em particular ou conjunto de tarefas no sistema.
Linux-SRT
[editar | editar código-fonte]O Linux-SRT é uma versão aprimorada do Linux padrão que implementa uma política de escalonamento de tempo-real flexível (sotf real-time). Esse sistema pode fazer a alocação de recursos, garantindo um limite mínimo de utilização. Esse limite pode não ser alcançado devido a algum fator, no entanto, a alocação real obtida estará muito próxima da especificada.
Como a alocação de tempo de processamento não é suficiente para garantir o comportamento previsto para a aplicação, esse modelo provê, Além de um novo escalonador de uso do processador, uma nova política de agendamento de disco [CI01].
O Linux padrão possui três políticas de escalonamento de processos para utilização da CPU: prioridades, FIFO e tempo-real. O Linux-SRT habilita mais três políticas de escalonamento. A primeira permite que as aplicações especifiquem uma quantidade fixa de uso do processador em um determinado período. A segunda é utilizada para manter uma aplicação suspensa, enquanto a última define que uma aplicação só pode executar quando o processador estiver ocioso.
As mesmas políticas foram implementadas para o agendamento do uso da banda de disco. Foram criadas mais três políticas, uma onde a aplicação define uma quantidade fixa de uso da banda, outra que fará com que as requisições de acesso a disco sejam postergadas e a última que permite o processo utilizar a banda de disco somente quando ela estiver ociosa.
A contribuição do Linux-SRT é combinar escalonadores de vários dispositivos, resultando em um sistema com controlamento de QoS realmente integrado.
A unidade de alocação dos recursos é chamada de reserve, e é um conjunto de processos definido pelo utilizador. Somente um processo pode ser incluído no reserve por vez.
E possível definir tanto uma quantidade mínima quanto máxima de utilização dos´ recursos, no entanto, os ajustes só podem ser realizados em tempo específico de configuração.
Dynamic Soft Real-Time CPU Scheduler
[editar | editar código-fonte]O sistema DSRT — Dynamic Soft Real-Time CPU Scheduler [Jac02] — implementa um escalonador de uso do processador em nível de utilizador (ou seja, fora do núcleo) capaz de garantir tempo de processamento em aplicações de tempo-real que suportem pequenos atrasos (flexíveis).
Por ser um escalonador de tempo-real flexível, esse modelo tenta cumprir os prazos determinados em contratos de QoS, mas pode ser influenciado por interrupções ou faltas de página. O objetivo desse modelo é prover um mecanismo para permitir que aplicações multimídia de tempo-real possam ser executadas adequadamente.
As requisições de alocação de CPU são feitas utilizando 3 (três) argumentos: a quantidade de reserva do recurso, a duração da reserva e o momento do início da reserva. Não sendo possível garantir o uso do processador de acordo com o estipulado pela requisição, o sistema oferece a possibilidade de diminuir a reserva, ou diminuir a duração da reserva ou mesmo alterar o início da reserva.
A arquitetura do DSRT mostra que ele se ajusta bem para aplicações multimídia que, geralmente, possuem tempo de duração bem determinado, necessitam de acesso privilegiado aos recursos e toleram o não cumprimento exato do contrato de QoS.
Por se tratar de um escalonador que executa em user mode, a sua portabilidade é facilitada, tanto que existem versões do DSRT para Linux, SunOS, Windows NT e Irix. Não há necessidade de alterações no núcleo do sistema operacional para implementõ-lo.
Infelizmente esse sistema não é granular, ou seja, trata somente aplicações que necessitam ser modificadas para que possam utilizar o mecanismo de reserva de recursos implementado pelo DSRT. E importante salientar que esse sistema não é dinâmico, pois´ é necessário informar os requisitos de execução no lançamento do processo.
Não há suporte para a definição de limites máximos de uso do processador.
Cap Processor Usage
[editar | editar código-fonte]Também chamado de CPUCap, consiste de um patch para o núcleo do Linux que permite limitar o quanto um processo pode utilizar o processador [Gol05].
Esse modelo de gerência de recursos não cria uma nova política no núcleo do Linux, somente altera a política dos processos comuns, adicionando uma verificação que torna possível a aplicação de limites máximos de utilização da CPU para algum processo específico.
A tabela de controlo de processos do Linux também é alterada, sendo adicionada a ela informações sobre os limites de uso do processador para aquele processo. A granularidade desse sistema é o processo, não permitindo que limites sejam impostos sobre qualquer tipo de agrupamento de processos. Não é possível definir limites inferiores para os processos. Há pouca documentação disponível, e no momento a versão mais atual é para o núcleo do Linux 2.6.6.
Memória
[editar | editar código-fonte]Todos os recursos possuem mecanismos que hierarquizam os processos a fim de permitir o uso adequado. A memória, no entanto, possui mecanismos pouco configuráveis que, na maioria das vezes, não permitem a interferência do administrador.
Com o intuito de permitir que o administrador possa interagir na política de decisão de uso da memória, esse modelo prevê três abordagens para o controlo desse recurso:
• Quantidade de páginas do processo (ou grupo) residentes em memória física (RSS resident set size);
• O número de faltas de página que ocorre;
• Quantidade de páginas em memória virtual.
O primeiro especifica quantos quadros de páginas um processo (ou grupo) pode utilizar, o que equivale a dizer quantos KBs o processo pode utilizar da memória RAM. O segundo especifica com que frequência ocorrerá as faltas de página para o processo (ou grupo) e o último define o limite de páginas que podem estar residentes na memória virtual.
Memória física
[editar | editar código-fonte]Como já foi dito, um processo tem o seu código e os seus dados armazenados em páginas, que podem estar tanto alocadas na memória física quanto em disco. A quantidade de páginas que o processo possui alocada em memória física é conhecida como RSS, ou tamanho do conjunto residente.
O modo de controlo, quando utilizando esse método para tratar as regras de limite inferior e superior, é limitar o valor mínimo e máximo, respectivamente, que o RSS pode atingir. Esse recurso é considerado preemptível, visto que se uma página de processo não tem o direito de permanecer em memória física ela pode ser transferida para a área de swap sem corromper a execução do processo.
As regras de limite superior delimitam o RSS máximo para o processo (ou grupo). Assim, não é permitido ao processo manter mais páginas em memória física do que o especificado pela regra. Caso isso ocorra ele terá algumas de suas páginas transferidas para o swap a fim de satisfazer a condição da regra.
Para regras de limite inferior o que é especificado é o número mínimo de páginas alocadas em memória física para o processo (ou grupo). Isso significa que se o processo possuir páginas suficientes para ocupar todo o valor estipulado pelo limite inferior, elas ficarão alocadas em memória física. Porém, se o processo não possuir páginas suficientes, o recurso será utilizado por outros processos até que sejam requeridas novas alocações de página pelo processo (ou grupo) controlado por esse tipo de regra.
Deve-se notar que a soma dos valores de todas as regras de limite inferior não pode ultrapassar o número máximo de quadros disponíveis no sistema. Caso isso ocorra a regra deve ser descartada.
Frequência das faltas de página
[editar | editar código-fonte]Uma falta de página ocorre quando um processo que está sendo executado possui uma das páginas necessárias para sua execução alocada em swap. A falta de página ocorre para informar ao sistema operacional que uma página necessária para a execução do processo se encontra em disco, e dessa forma, ele possa transferí-la para a memória física.
Um número grande de faltas de página pode significar que uma ou mais páginas de memória que um processo usa constantemente estão sendo transferidas para a área de swap pela necessidade que o sistema tem de utilização de memória física por outros processos devido a escassez de memória livre. Também pode significar que um processo seja demasiadamente grande e está fazendo uso de várias páginas diferentes que ainda estão em disco. Impor limites sobre a quantidade de faltas de página que ocorrem traduzse por manter um determinado número de páginas ou em memória física ou em swap de acordo com o que especificar a regra.
Para quantificar a frequência de faltas de página deve-se encontrar a relação do número de faltas de página, que ocorrem para um ou mais processos, com um determinado período. Como não é possível saber quantas faltas de página ocorrerão em um período de tempo pré-definido, visto que não se pode prever a necessidade de uso das páginas, deve-se utilizar uma outra maneira de estipular um período. Neste modelo foi utilizado uma quantidade c de faltas de página ocorridas como período. Assim sendo, um processo tem a sua frequência de faltas de página medida pelo número de faltas de página que ele gerou durante c faltas de página ocorridas no sistema. Por exemplo, se c = 100, um processo P1 que gerou 15 faltas de página durante as 100 últimas faltas ocorridas no sistema todo, tem 15% de frequência de faltas de página. Neste modelo, as faltas de página do sistema devem ser contadas na forma de ciclos de tamanho c.
O limite inferior de uma regra de controlo da frequência das faltas de páginas especifica que de todas as faltas de página ocorridas no sistema durante o período c, o processo (ou grupo) a qual a regra se refere pode no máximo gerar a quantidade de faltas de página especificado pela própria regra. Um método para se implementar isso é manter em memória física uma quantidade suficiente de páginas do processo (ou grupo) pertinentes a regra de forma que se ele necessitar de algum dado ou instrução eles já estejam em memória física, e se estiverem em swap, a quantidade de páginas transferidas não vai ser suficiente para ultrapassar o valor especificado pela regra neste ciclo c.
O algoritmo para substituição das páginas pode ser o mesmo utilizado pelo sistema operacional hospedeiro. Assim sendo, caso a página retirada seja de um processo pertencente a regra, pode-se acarretar no descumprimento da regra se a página retirada for requerida novamente antes de se completar o ciclo. No entanto, um algoritmo que não permita a retirada dessa página da memória se tornaria um simples método de manter todas as páginas do processo na memória, o que pode não ser desejado.
Já o limite superior determina a quantidade máxima de faltas de página que os processos pertencentes à regra podem gerar durante o período c. Caso os processos atinjam o limite de faltas de página permitido, eles devem esperar um novo ciclo c para continuarem a sua execução, ficando bloqueados. E fato que se houver demora para a conclusão do´ ciclo, os processos bloqueados devido a regras de limite superior podem também demorar para tornarem-se prontos para execução novamente. Assim sendo, é bom que o ciclo expire após um tempo pré-determinado.
Os processos que não participam de nenhuma regra continuam a seguir a mesma política de decisão estipulada pelo sistema operacional.
Memória virtual
[editar | editar código-fonte]A utilização da memória virtual também pode ser controlada de forma que não se permita que um processo (ou grupo) possua uma quantidade de páginas em memória virtual maior do que especificado, ou que se garanta espaço de alocação para as páginas do processo (ou grupo) mesmo quando a memória virtual esteja alcançando o seu limite (memória física + área de swap saturadas).
As regras para este controlo devem estipular valores absolutos do número mínimo ou máximo de páginas que podem ser alocadas na memória virtual.
Para as regras de limite superior, os processos que são alvo das regras não podem manter um número maior de páginas em memória virtual do que o imposto pela regra. Assim sendo, quando estes processos alocarem memória, o limite estipulado é verificado e, caso seja ultrapassado, o sistema não permite a nova alocação de memória e retorna um código de erro.
Se no momento da criação de uma regra de limite superior, os processos afetados pela regra já ultrapassam o limite fixado, deve-se permitir que os processos executem acima do limite, negando qualquer nova tentativa de alocação até que eles liberem espaço em memória virtual e o limite seja satisfeito.
Os processos que fazem parte de regras de limite inferior tem o privilégio de reserva de espaço na área de swap no momento da criação da regra de acordo com o valor definido por esta, se houver espaço livre suficiente. Caso não haja, a regra não é criada. As páginas em swap dos processos que já estão em execução no momento da criação da regra também devem ser contadas e marcadas como reservadas.
Ao transferir uma página da memória física para a área de swap, deve-se verificar se a página pertence a um processo de uma regra de limite inferior. Se o for, deve-se alocá-la no espaço previamente reservado.