No Partes 1 e 2, foi visto como utilizar o sistema de nível de execução e ferramentas relacionadas para reduzir dramaticamente o uso de memória em um PS3 que executa Linux, deixando mais memória disponível para compilação e serviços semelhantes. Para encerrar isso, serão examinadas mais algumas coisas que valem a pena, incluindo pelo menos uma tarefa razoavelmente pesada: tornar a área de cobertura do X11 mais enxuta.

O problema com o X11 é que você pode precisar muito dele. Isso é um problema porque a área mínima de cobertura de memória que eu ví só para o servidor X em meu PS3 era de cerca de 40 MB, que é, de longe, demasiada memória disponível para sacrificar apenas por algumas figuras bonitas. (Sim, eu realmente aprendi a utilizar UNIX® em um terminal de texto simples. Por que você está olhando para mim de forma engraçada?) Dito isso, ele realmente é muito útil às vezes e existem programas os quais não tem sentido executar sem gráficos.

Executar X11 em Outra Máquina

Assim, o X11 é necessário, mas o PS3 não tem memória suficiente para executá-lo confortavelmente. Você tem uma opção clandestina: executar na rede. Clientes X poderiam ser configurados para execução em seu PS3, com um servidor X em um sistema remoto. Isso não é de fato excepcionalmente rápido—o hypervisor parece diminuir a velocidade da interligação de redes um pouco a partir do desempenho de gigabit nominal que o hardware possui—mas se a velocidade mais alta possível não for necessária, ele é realmente bem suportável. Você tem algumas opções ao configurar isso. Primeiro, será necessário executar um servidor X em uma outra máquina.

Há um rumor sem fim de que o S.O. X será executado em um PS3, porque um dos filmes de demo de tecnologia Cell/B.E. foi uma vez reproduzido em um Mac em uma feira comercial e as pessoas ficam postando uma figura disso insistindo que é a prova. Bem, vamos piorar a situação; eu utilizarei o servidor X11 nativo em uma máquina de S.O. X para demonstrar isso. De fato, o X é satisfatoriamente portátil e os truques essenciais são os mesmos em qualquer lugar.

Primeiro, inicie seu servidor X e obtenha um prompt você mesmo; execute um programa de terminal de qualquer classificação que queira. Eu escolhi xterm. Agora, existem duas maneiras pela frente. Uma é utilizar o recurso de encapsulamento de X do ssh para permitir que seham encaminhados pedidos do X do cliente (que é o PS3) ao servidor (que é o Mac, nesse caso). A outra é utilizar X diretamente sobre a conexão. Cada uma delas tem pontos fortes e fracos; no caso de uma rede local, sobre a conexão pode ser mais fácil de explicar e utilizar. Primeiro, calcule qual é seu DISPLAY do servidor X. Em seu terminal X, faça eco na variável de ambiente DISPLAY; ela provavelmente será ":0.0". Isso significa que seu servidor X está executando uma exibição denominada "0.0". Os dois pontos (:) separam o nome do host do nome de exibição. Se o seu laptop fosse denominado "laptop," o nome completo da exibição seria "laptop:0.0". (Quando o nome é omitido, X utiliza hacks inteligentes para acessar uma exibição local mais rapidamente.)

Agora, se você for apenas dar uma passada sobre o PS3 e configurar a variável de ambiente DISPLAY como, por exemplo, "laptop:0.0" e executar um xterm, descobrirá uma falha trágica nesse esquema: Permissão negada. Por padrão, não permitirá que clientes arbitrários em um host remoto sejam executados na exibição local. Esse é um recurso de segurança; obviamente, você desejará derrubá-lo. A maneira mais simples de fazer isso é permitir que os clientes em seu PS3 acessem o servidor X. Na máquina local, execute o comando xhost +<máquina>, em que <máquina> é o nome do host ou endereço IP de seu PS3. Eu nunca me importei em configurar DNS para meu bloco dinâmico não-roteável; assim eu utilizei xhost +10.10.10.134. Com isso feito, executar comandos X no PS3 funciona; eles aparecem no Mac, sem a sobrecarga substancial de memória de um servidor X em execução no PS3.

Encaminhar Pedidos do X11

Agora, há uma outra opção. O comando ssh (você deixou o sshd em execução, certo?) pode encaminhar pedidos do X11. Quando você executar ssh com acesso a um servidor X, passá-lo para a opção -X o faz encaminhar pedidos do X; de fato, a opção -Y pode ser preferível, já que ativa o encaminhamento "confiável", o que contorna mais recursos de segurança. (Você deseja contorná-los porque de outra maneira não poderá, digamos, abrir janelas.) Opcionalmente, é possível examinar a opção -C , que especifica compactação de dados, incluindo pacotes do X11. Isso é útil em redes lentas, mas não tão útil em redes rápidas. Tente ambas as formas para ver. A sintaxe para essa é mais fácil de certa forma; simplesmente ssh -X <ps3> e no PS3, inicie executando comandos que utilizam X. Dessa maneira, o PS3 não tem a sobrecarga de memória do servidor, apenas aquela dos clientes. Hora de iniciar o konquerer, certo? Mas o konqueror utiliza cerca de 20 MB, mais 7,5 MB para kded, 5,8 MB para klauncher, 5 MB para kio_file, 4,7 MB para kdeinit...

Isso, é claro, realça um problema secundário: mesmo sem o servidor, aplicativos X podem utilizar muita memória. Transferir o servidor melhora a memória disponível, mas não elimina completamente o problema.

Voltar para parte superior

Tente Enxugar o Servidor

O acesso remoto simplesmente pode não ser rápido o suficiente ou você pode não ter um servidor X conveniente para utilizar. Existe uma outra opção: execute o servidor localmente, mas sem KDE ou Gnome. Para fazer isso, provavelmente é necessário omitir o gerente de tela 5 X de nível de execução e a janela de login; como alternativa, efetue login em um console e inicie X você mesmo. A maneira clássica para fazer isso é simplesmente executar o programa xinit , que executa os comandos em seu arquivo .xinitrc, localizado em seu diretório de início. Observe que esses comandos são executados sequencialmente; se você deseja mais de um programa ao mesmo tempo, alguns primeiros precisam ter segundo plano (coloque & no final da linha). Por exemplo, aqui está um .xinitrc que será suficiente:

                
		 xterm &
		 exec twm
 

X é finalizado quando o programa que estava executando como sua "sessão" termina; nesse caso, esse é o programa twm que o xinitrc executou como seu último comando. Algumas pessoas preferem utilizar um xterm como o programa de sessão e executar o gerente de janelas no plano de fundo. A decisão é sua.

Se você utilizar esse arquivo .xinit e executar xinit, provavelmente verá um plano de fundo cinza cheio de pontos e um cursor do mouse com uma espécie de coisa esquisita, hum, de nove painéis. Esse é um xterm, que o espera decidir onde colocá-lo. O recurso principal do gerente de janelas do twm é que ele é muito pequeno; ele não o ajuda muito, praticamente lhe dá confiança de saber o que deseja. Por outro lado, sua área de cobertura de memória total de um pouco acima de 2 MB é visivelmente menor que aquela de algo maior, como Gnome ou KDE. Em meu sistema, o programa xterm realmente ocupou mais espaço que o twm, embora a maior parte do espaço tenha ido para o servidor X, com um tamanho virtual de 62 MB e um conjunto residente de 34 MB realmente em RAM. Isso é bastante grande. O que podemos fazer a respeito?

Não muito. Pela lógica, a primeira coisa a fazer seria desativar módulos. Se você já teve que fazer isso antes, está, sem dúvida, familiarizado com o processo. Vá em /etc/X11, edite xorg.conf (é necessário ter privilégios de administrador para fazer isso) e comente a linha de módulos que não é necessária.... Só que não existe nenhum módulo em xorg.conf. Em servidores X.org modernos, o comportamento padrão é carregar tudo e ver o que cola. Convenientemente, é fácil substituir isso; se você fornecer uma seção Módulos, apenas as coisas que pedir serão carregadas. Em um sistema sem hardware gráfico em funcionamento, as várias opções relacionadas a GL são bastante sem valor; aqui está o que eu acabei utilizando:

                
		 Section "Módulo"
			 Load "extmod"
			 Load "type1"
			 Load "freetype"
		 EndSection
 

Acredito que isso realmente não muda muitas coisas; isso trouxe meu servidor X de 34 MB para, acredite, 33 MB. O problema real, é claro, é a imensa quantidade de memória utilizada pelo buffer interno que está sendo gravada no dispositivo de buffer de quadro: 1280x768 aproximadamente e o buffer de quadro funciona, realmente, apenas no modo de 32 bits. Reduzir o tamanho do buffer de quadro realmente pode ajudar bastante—a um custo substancial para seus bens de tela, é claro. Por exemplo, alternando para um modo 480p, de tela não-inteira (que é substancialmente menos que 480 pixels de altura), eu descobri que o X estava utilizando cerca de 10 MB de memória real; mesmo 720p, de tela não-inteira, utilizou menos (25 MB) do que eu estava obtendo no modo WXGA. Se você estiver próximo da margem, seria melhor reduzir um pouco. É uma pena que o PS3 não possua uma gama mais ampla de modos de vídeo suportados.

Voltar para parte superior

Outras Maneiras de Enxugar Espaço

Há um pouco mais que é possível fazer para enxugar espaço. Se você não estiver utilizando os múltiplos consoles de login de seu PS3, pode desligar aqueles que não estiver utilizando. Ao contrário de outros recursos relacionados ao nível de execução, esses são realmente codificados diretamente em /etc/inittab. A configuração padrão para Fedora é fornecer com seis consoles ativados; eu acho que a tela é mais útil. Aqui está o que você mudaria em /etc/inittab para desligar cinco deles:

                
		 # Executar gettys em níveis de execução padrão
		 1:2345:respawn:/sbin/mingetty tty1
		 2:2345:off:/sbin/mingetty tty2
		 3:2345:off:/sbin/mingetty tty3
		 4:2345:off:/sbin/mingetty tty4
		 5:2345:off:/sbin/mingetty tty5
		 6:2345:off:/sbin/mingetty tty6
 

Alterações nos arquivos de nível de execução são reconhecidas quando você muda para um novo nível de execução. O que acontece com as alterações em inittab? Para permitir que init saiba que o inittab foi alterado, execute /sbin/init q. O argumento q , em vez de indicar um nível de execução, instrui init para recarregar seus arquivos de configuração. (Eu acho que talvez ele signifique consulta, mas isso não está documentado.)

Se tarefas de plano de fundo regulares não forem necessárias, é possível encerrar anacron e crond; se não se importar em efetuar codificação permanentemente em suas configurações de rede, pode encerrar dhclient. Um método particularmente favorável pode ser substituir bash por dash (consulte Tamanho do Shell). Mesmo assim, você está bem na margem aqui; por isso, a única maneira de recuperar memória é mudar a estrutura subjacente do buffer de quadro do ps3 ou o hypervisor, o que não é prático.

Por outro lado, iniciar com um sistema que já havia iniciado a troca antes de obter um prompt e finalizar com um sistema que tinha acima de 100 MB de armazenamento livre com dois shells, um processo principal e o sshd em execução, não é uma ação pequena. Enquanto é fácil menosprezar isto a partir das imponentes alturas de laptops com 2 GB ou mais de memória, o fato é que uma grande quantidade de desenvolvimento de software torna-se bem factível quando a sua plataforma de desenvolvimento tem 100 MB de memória livre; é suficiente que muitas construções poderão permanecer inteiramente dentro do cache de buffer, economizando bastante tempo, sem falar de poder, na maioria das vezes, evitar a troca exceto sob circunstâncias extremas.

Conclusão

Com esses ajustes, o PS3 torna-se um ambiente de desenvolvimento viável e até um tanto espaçoso. (Ele é um dos ambientes mais acessíveis para alguém que procura envolver-se com o Cell Broadband Engine.) Ele se mantém responsivo durante compilações e as compilações são executadas notavelmente mais rápidas do que costumavam. Enquanto a memória fornecida não é tão grande para um sistema de desktop, com reprodutores de vídeo, navegadores da Web e clientes de e-mail, todos em execução ao mesmo tempo, ela é certamente adequada para um esforço de desenvolvimento, e de fato, com o gasto adicional do GNOME e do KDE fora do normal, ela pode até gerenciar algum trabalho de desktop. É bem possível que futuras atualizações no firmware do PS3 melhorarão as coisas, como poderiam as novas versões ou drivers do kernel. Apenas lembre-se de ficar concentrado no que precisa do sistema e vá em frente e desative recursos que não estiverem sendo utilizados.

Recursos

Aprender

• Consulte todas as partes na série Desenvolvimento de Linux no PlayStation 3.
  
  
• "Programando Aplicativos de Alto Desempenho no Processador Cell BE, Parte 1: Uma Introdução ao Linux no PLAYSTATION 3" (developerWorks, janeiro de 2007) e "PS3 fab-para-lab, Parte 1: Construção do Equipamento de Laboratório Linux a partir de um Sony PLAYSTATION 3" (developerWorks, maio de 2007) são os primeiros artigos em outra série do developerWorks sobre a execução do Linux no PS3.
  
  
• Twm é seu bom amigo se você estiver em uma situação difícil com relação à memória.
  
  
• Sistemas embarcados frequentemente utilizam BusyBox para reduzir requisitos de espaço. A BusyBox é mais útil em termos de espaço em disco do que de memória, mas ela ajuda com tudo.
  
  
• Aprenda mais do que jamais precisou saber sobre cron e anacron e bash e dash e esses outros utilitários Unix excelentes a partir da wikipedia. Para dhclient, consulte man dhclient.
  
  
• Saiba mais sobre ssh.
  
  
• O Cell Broadband Engine Resource Center é o recurso definitivo para todas as coisas de Cell/B.E.
  
  
• Na zona Linux do developerWorks, encontre mais recursos para desenvolvedores Linux e varra nossos artigos e tutoriais mais conhecidos.
  
  
• Consulte todas as dicas de Linux e tutoriais de Linux no developerWorks.
  
  
• Fique atualizado com eventos técnicos e Webcasts do developerWorks.
  
  

Obter produtos e tecnologias

• Solicite o SEK para Linux, um conjunto de dois DVDs que contém o software de período experimental IBM mais recente para Linux a partir do DB2®, Lotus®, Rational®, Tivoli®e WebSphere®.
  
  
• Com o Software de período experimental IBM, disponível para download diretamente do developerWorks, construa seu próximo projeto de desenvolvimento em Linux.
  
  

Discutir

• Envolva-se com a comunidade do developerWorks através de blogs, fóruns, podcasts e tópicos da comunidade em nossos novos espaços do developerWorks.
  
  

Sobre o autor

Peter Seebach coleciona dispositivos pequenos que executam em Linux. Ele está cansado de ouvir piadas sobre criar um cluster Beowulf a partir deles.

Classificar este artigo

Comentários

Voltar para parte superior

Índice

• Executar X11 em Outra Máquina
• Encaminhar Pedidos do X11
• Tente Enxugar o Servidor
• Outras Maneiras de Enxugar Espaço
• Conclusão
• Recursos
• Sobre o autor
• Comentários

Conheça a IBM da sua cidade

A IBM está mais perto do que você imagina!

---

Saiba mais