image1 image2 image3 image4 image5 image6 image7 image8 image9 image10
Data de criação:
Data de publicado:
Acessos: 2002

Nada como começar 2014 com um post sobre nvidia.  Não que 2014 tenha começado agora, mas não tive muito assunto pra escrever até o momento (na verdade tive, mas a inércia de 2013 foi mais forte).

Estou trabalhando num ambiente que usa pesadamente linux containers, os lxc, que é uma forma de virtualização.  Pra minha triste surpresa, muitas funcionalidades não ficam ativas no lxc com o kernel-pf.  Então resolvi voltar pro bom e velho kernel Linux padrão, baixado diretamente de https://www.kernel.org

Compilação feita, com parâmetros pra funcionamento dos linux containers (é preciso ativar cgroups em toda sua funcionalidade) e, antes do boot, aparece um upgrade dos drivers da nvidia.  Já que ia fazer um reboot, resolvi fazer tudo de uma vez.

O boot do kernel linux-3.13.0-helio.3 (3ª versão, as outras duas ou eu esqueci algo, ou falhou em algum parâmetro que deixei fora) foi tranquilo mas o Xorg... esse subiu com noveau, bem inferior ao drive da nvidia.  Ao tentar carregar o módulo da nvidia manualmente, pra descobrir qual o problema, surgiu a seguinte mensagem:

[ 89.005614] nvidia: Unknown symbol acpi_os_wait_events_complete (err 0)
[ 386.837191] nvidia: Unknown symbol acpi_os_wait_events_complete (err 0)

Procurando pela Internet, descobri que justamente o pacote novo da nvidia, nvidia-331 (ou nvidia-331_331.38-0ubuntu0.0.1~xedgers~precise2_amd64.deb), tem esse erro com kernels 3.13, pois a função EXPORT_SYMBOL(acpi_os_wait_events_complete) foi removida do mesmo.

A correção não é muito complexa.  Basta aplicar a seguinte correção dentro de "/usr/src/nvidia-331-331.38", que foi criado durante a instalação do pacote:

--- nvidia-331-331.38/nv-acpi.c.orig    2014-01-21 11:44:59.485055493 +0100
+++ nvidia-331-331.38/nv-acpi.c 2014-01-21 11:44:22.664056579 +0100
@@ -301,13 +301,13 @@
             "NVRM: nv_acpi_remove: failed to disable display switch events (%d)!\n", status);
     }
 
-    if (pNvAcpiObject->notify_handler_installed)
+    /* if (pNvAcpiObject->notify_handler_installed)
     {
         NV_ACPI_OS_WAIT_EVENTS_COMPLETE();
 
         // remove event notifier
         status = acpi_remove_notify_handler(device->handle, ACPI_DEVICE_NOTIFY, nv_acpi_event);
-    }
+    }*/
 
     if (pNvAcpiObject->notify_handler_installed &&
         ACPI_FAILURE(status))

É um comentário em toda a parte de código que usa a função problemática.  Uma vez que a chamada de kernel não existe mais, não deve causar grandes impactos.  Então basta atualizar o dkms, que no meu caso fiz com o kernel de nome linux-3.13.0.helio-3.

dkms remove -m nvidia-331 -v 331.38 -k 3.13.0.helio-3
dkms build -m nvidia-331 -v 331.38 -k 3.13.0.helio-3
dkms install -m nvidia-331 -v 331.38 -k 3.13.0.helio-3

Com isso o módulo novo, com o patch acima, é construído.  Então basta rebootar pra ter o kernel novo rodando e correr pro abraço :-)

 

Data de criação:
Data de publicado:
Acessos: 2639

Depois de uma longa batalha pra atualizar meu PC, consegui deixar tudo redondo pra jogar L4D2 (Left for Dead 2) com o pessoal.  E sobre o Ubuntu.

Um dos empecilhos era em relação às configurações de controle do jogo, que por padrão usa o mouse e o teclado.  Eu até tentei usar no início, mas estou acostumado com os consoles, xbox360 e ps3, e com seus respectivos controles.  Então era um sofrimento jogar.

Tentei utilizar os controles dos dois no Linux, mas vi na Internet que o melhor controle é o do xbox, mas não o wireless, o cabeado.  Sem problemas.  Sai caçando um e comprei na loja xing-ling de origem questionável mais próxima (na av. Paulista).

Quando fui jogar, nova decepção: não mapeava corretamente os movimentos.  Mas uma alma caridosa conseguiu fazer o mapeamento usando um driver através do programa xboxdrv (tem pra Ubuntu).

Criei então os seguinte script pra mapear o controle e jogar com os amigos:

#! /bin/sh
# Name: xbox360controler_setup.sh
# Source http://ubuntuforums.org/showthread.php?t=2002622

case `whoami` in
        root) echo "Running as root";;
        *) echo "You must run it as root.  Using sudo for that."
           sudo $0
           exit 0
esac

rmmod xpad
modprobe uinput
modprobe joydev
rmmod xpad

xboxdrv \
        -s \
        --type xbox360 \
        --deadzone 9000 \
        --dpad-as-button \
        --trigger-as-button \
        --ui-axismap "x2=REL_X:10,y2=REL_Y:10,x1=KEY_A:KEY_D,y1=KEY_W:KEY_S" \
        --ui-buttonmap "tl=KEY_LEFTSHIFT,tr=KEY_LEFTCTRL" \
        --ui-buttonmap "a=KEY_SPACE,b=KEY_C,x=KEY_1,y=KEY_R" \
        --ui-buttonmap "lb=KEY_Q,rb=KEY_E" \
        --ui-buttonmap "lt=BTN_RIGHT,rt=BTN_LEFT" \
        --ui-buttonmap "dl=KEY_LEFT,dr=KEY_RIGHT,du=KEY_UP,dd=KEY_DOWN" \
        --ui-buttonmap "back=KEY_ESC,start=KEY_ENTER"

Boa jogatina e lembre-se: se for jogar, pode me chamar.  Não garanto lá um desempenho muito bom, mas a diversão é garantida.

Data de criação:
Data de publicado:
Acessos: 2297

Finalmente resolvi adicionar meu próprio PPA, Personal Package Archive - ou Arquivo de pacote pessoal, no Launchpad do Ubuntu. Isso vai me permitir distribuir facilmente os pacotes que crio. São para uso meu, baseado num Ubuntu LTS 12.04, mas podem ajudar mais pessoas.

Pra começar, fiz um upload do backport do python-twitter 1.0.1, que funciona com a API v1.1.

python-twitter_1.0.1-1_all.deb

Para quem desejar usar meu repositório, deve bastar adicionar o PPA.

sudo add-apt-repository ppa:helioloureiro

Minha chave PGP ainda não foi adicionada, mas isso deve ser corrigido em algum commit do sistema, o que talvez demore 1 dia. Até lá, meu pacote python-twitter não aparecerá como disponível.

Meu próximo upload deve ser dos pf-kernel. Já tenho compilado as versões 3.9.5 e 3.10.0.

Data de criação:
Data de publicado:
Acessos: 5101

Finalmente chegou o momento em que me rendi novamente ao appeal corporativo e voltei a utilizar um equipamento da empresa, e não mais um laptop meu e pessoal.

Optei por um equipamento que fosse homologado internamente para rodar Linux, e então recebi um considerado "high end laptop": um notebook HP EliteBook 8570w.

Carregando o Ubuntu.

A instalação foi bem tranquila.  Bastou inserir o pendrive e seguir com os passos de instalação do Ubuntu via rede.

Sem mexer em nada, o sistema já saiu funcionando: webcam, wifi, som, etc.  A única coisa que ficou faltando, mas que foi corretamente notificada pelo Ubuntu, foi a placa de vídeo nvidia, e para instalar os drivers proprietários.  E que bela placa de vídeo: NVIDIA GPU Quadro K1000M (GK107GL) com 2 GB de memória dedicada.  Alguns sites não recomendam essa placa para jogos, mas com certeza esse não é o meu objetivo com esse equipamento.

Mas vamos ver um pouco mais do hardware:

  • Processador Intel Core i7-3520M de 2.9 GHz.OK
  • Placa de vídeo NVIDIA GPU Quadro K1000M (GK107GL) com 2 GB de RAM DDR3. OK
  • Placa gigabit ethernet Intel 82579LM. OK
  • Webcam Primax Electronics (ou HP HD Webcam). OK
  • Modem HP hs2350 HSPA+ MobileBroadband (modem 3G+). Não sei
  • Placa wireless Intel Centrino Ultimate-N 6300. OK
  • 3 portas USB. OK
  • 1 porta e-SATA. Não sei
  • 1 saída VGA. OK
  • 1 saída DisplayPort. Não sei
  • 1 unidade de DVD recorder. Não sei
  • 1 leitor de cartão SD/MMC. Não sei
  • 1 porta firewire. Não sei
  • Saída de áudio Intel (interno) e Nvidia (DisplayPort). OK e Não sei
  • HD de 320 GB de 7200 RPM. OK
  • 8 GB de RAM DDR3 de 1600 MHz. OK
  • Tela de 15.6 polegadas com resolução de 1920x1080. OK

Ainda tem uma porção de coisas que não consegui identificar.  Existe no hardware, mas não vejo nas saídas de lspci e lsusb, ou mesmo lshw.  Um bom exemplo é uma porta de modem que tem na parte de trás do laptop.

Modem dialup?

Minha primeira impressão sobre o laptop é... ele é um monstrobook.  É enorme e pesado.  Pesa 3 Kg pela descrição técnica, mas parece que são uns 15 Kg.  É um hardware grande e confortável para digitar, mas tão grande que tem até teclado numérico junto. E deixa isso claro pela informação na traseira, onde se descreve como "Workstation", não um notebook ou laptop. Para quem estava acostumado com um laptop fofucho de 13 polegadas, é uma mudança muito grande.

Tem ainda uma série de botões para uso ou do touchpad ou do pointer que fica no meio do teclado, algo desnecessário.  As teclas são confortáveis, mas poderia ter ao menos iluminação.

Os botões para habilitar/desabilitar wireless e som, que ficam no topo à direita, funcionam sem problemas.  Os outros dois botões que ficam por lá também, para acesso rápido à Internet e para uma... calculadora?  Esses não funcionam para nada.  O de acesso à Internet dá um refresh na página web que se está lendo.

Sobre o botão de bloqueio de som, esse não funcionou _exatamente_ de primeira.  Ele mostrava o bloqueio do som, mas sem efeito concreto disso.  O motivo foi que pulseaudio apontava pra saída do DisplayPort como principal.  Bastou utilizar o aplicativo pavucontrol e modificar o padrão pra saída de som normal que o botão funcionou corretamente.

AntesDepois

O site da HP dá bastantes detalhes sobre o equipamento e seu uso em potencial.

HP EliteBook 8570w Mobile Workstation - Portable Powerhouse

o que chama a atenção é que esse é um hardware certificado para usar Linux.  Acho que nunca tinha usado um laptop que tivesse isso.  Não é certificado para Ubuntu, mas se funcionou com uma distribuição de Linux, funciona com todas.

 

E a HP chegou mesmo a fazer até um vídeo sobre o laptop.

 

É um equipamento legal, parrudo, mas pesado.  O carcaça é de aço escovado, o que dá um certo charme ao conjunto.  Faz falta também uma saída HDMI ao invés de DisplayPort.  E a autonomia da bateria é baixa, entre 2 e 3 horas apenas.  Estou gostando dele e espero que minhas costas se acostumem logo com o peso.  E espero que a próxima geração de laptops homologados pela empresa seja de ultrabooks...

 

TPL_COM_CONTENT_READ_MORERodando Linux no HP EliteBook 8570w
Data de criação:
Data de publicado:
Acessos: 3562

E fechando o ano de 2012, um último artigo sobre hibernação no Ubuntu 12.10, que é pra lembrar de entrar 2013 bem descansado :-)

Escrevo um artigo sobre a utilização do laptop sem ficar desligando, a guerra dos 100 dias, e seus benefícios e então me deparo justamente com um upgrade de sistema que não funciona com a hibernação.  E em menos de 6 meses.

Tudo começou quando decidi passar o laptop de 32 bits para 64 (processador Intel Core i3).  Minha limitação para não realizar tal tarefa antes era o sistema de SSL VPN, da Juniper, usado pela empresa para conectar remotamente.  O sistema de VPN inicia um applet java que instala e roda uma biblioteca de 32 bits.  

Já fazia algum tempo, eu vinha testando rodar isso em um modo "híbrido", com a funcionalidade de multi-arch ou com chroot de um ambiente de 32 bits.  Como tudo estava funcionando nos testes, resolvi mudar o sistema aproveitando as férias de fim de ano.

Eu estava com Ubuntu 12.04 para i386, LTS, e resolvi instalar o 12.10 para amd64.  Eu poderia ter escolhido um upgrade do sistema, que aparentemente funcionaria, mas resolvi fazer uma instalação nova, o que acabou me gerando a perda de dados do /home, mas essa é outra história.

Ao finalizar a instalação do 12.10 (e recuperar minha partição perdida - mas não completamente, duh!), eu me deparei com um kernel mais novo: 3.5.0-21-lowlatency.  Anteriormente eu estava rodando o 3.2.7-pf (post factum).  Não consegui fazer funcionar a hibernação de jeito nenhum.  Nem com pm-suspend, nem com pm-hibernate, nem com o novo método, o pm-suspend-hybrid.  Em todos os casos o sistema travava logo no início da hibernação e me deixava com uma tela preta, sistema operacional travado, mas máquina ligada.  Somente um procedimento de "dedo-off" conseguia desligar o laptop.  E sem nenhum log de problema por parte do ACPI.

Tentei recompilar o kernel, instalar outra versão, a versão sem lowlatency, enfim de tudo.  Mas sem resultados.

Por um acaso, notei um erro no sistema pelo "dmesg".  No começo achei que era problema da minha memória RAM.

[    5.974345] BUG: unable to handle kernel paging request at 0000000000ff1000
[    5.974351] IP: [] memcpy+0xd/0x110
[    5.974359] PGD 1b0dbc067 PUD 1b0db9067 PMD 0 
[    5.974363] Oops: 0000 [#1] SMP 
[    5.974366] CPU 2 
[    5.974367] Modules linked in: snd_page_alloc drm_kms_helper serio_raw drm 
coretemp cfg80211 kvm_intel i2c_algo_bit kvm videobuf2_vmalloc videobuf2_memops 
mxm_wmi wmi sony_laptop(+) intel_ips microcode mac_hid video mei lpc_ich btusb 
bluetooth xfs firewire_ohci firewire_core crc_itu_t sdhci_pci sdhci atl1c
[    5.974385] 
[    5.974387] Pid: 637, comm: modprobe Not tainted 3.5.0-17-generic #28-Ubuntu 
Sony Corporation VPCS110GB/VAIO
[    5.974390] RIP: 0010:[]  [] memcpy+0xd/0x110
[    5.974394] RSP: 0018:ffff8801b0d31c40  EFLAGS: 00010246
[    5.974395] RAX: ffff8801b0d31c90 RBX: ffff8801ae9545c0 RCX: 0000000000000001
[    5.974397] RDX: 0000000000000000 RSI: 0000000000ff1000 RDI: ffff8801b0d31c90
[    5.974398] RBP: ffff8801b0d31c58 R08: ffff8801b2218200 R09: 000000018040003e
[    5.974399] R10: 0000000000000000 R11: ffffffff813ad3e5 R12: ffff8801b0d31c90
[    5.974401] R13: ffff8801b0d31caf R14: ffff8801b22f4800 R15: 0000000000000135
[    5.974403] FS:  00007fb7feb92700(0000) GS:ffff8801bbc80000(0000) knlGS:0000000000000000
[    5.974404] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[    5.974405] CR2: 0000000000ff1000 CR3: 00000001b271d000 CR4: 00000000000007e0
[    5.974407] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[    5.974408] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[    5.974410] Process modprobe (pid: 637, threadinfo ffff8801b0d30000, task ffff8801b0d8c500)
[    5.974411] Stack:
[    5.974413]  ffffffffa01a8893 0000000000000009 0000000000000035 ffff8801b0d31ce8
[    5.974416]  ffffffffa01a9b69 ffff8801b16986a0 ffff8801b0067800 ffff8801b0d31c80
[    5.974419]  ffffffff00000000 0000000000000009 0000000000000000 0000000000000000
[    5.974422] Call Trace:
[    5.974430]  [] ? sony_nc_buffer_call.constprop.12+0x43/0xa0 [sony_laptop]
[    5.974435]  [] sony_nc_function_setup+0x2f9/0xab0 [sony_laptop]
[    5.974440]  [] sony_nc_add+0x1f8/0x660 [sony_laptop]
[    5.974446]  [] ? sysfs_do_create_link+0xeb/0x200
[    5.974451]  [] acpi_device_probe+0x50/0x11d
[    5.974457]  [] driver_probe_device+0x7e/0x220
[    5.974460]  [] __driver_attach+0xab/0xb0
[    5.974462]  [] ? driver_probe_device+0x220/0x220
[    5.974465]  [] bus_for_each_dev+0x55/0x90
[    5.974468]  [] ? 0xffffffffa01b4fff
[    5.974470]  [] driver_attach+0x1e/0x20
[    5.974473]  [] bus_add_driver+0x198/0x270
[    5.974475]  [] ? 0xffffffffa01b4fff
[    5.974478]  [] driver_register+0x77/0x150
[    5.974483]  [] ? dmi_matches+0x53/0xc0
[    5.974485]  [] ? 0xffffffffa01b4fff
[    5.974488]  [] acpi_bus_register_driver+0x3e/0x47
[    5.974492]  [] sony_laptop_init+0x57/0x1000 [sony_laptop]
[    5.974498]  [] do_one_initcall+0x12a/0x180
[    5.974502]  [] sys_init_module+0xc2/0x230
[    5.974508]  [] system_call_fastpath+0x16/0x1b
[    5.974509] Code: 2b 43 50 88 43 4e 48 83 c4 08 5b 5d c3 90 e8 eb fb ff ff 
eb e6 90 90 90 90 90 90 90 90 90 48 89 f8 48 89 d1 48 c1 e9 03 83 e2 07  
48 a5 89 d1 f3 a4 c3 20 4c 8b 06 4c 8b 4e 08 4c 8b 56 10 4c 
[    5.974539] RIP  [] memcpy+0xd/0x110
[    5.974542]  RSP 
[    5.974543] CR2: 0000000000ff1000
[    5.974545] ---[ end trace 67f7b54c3f5c5271 ]---

Como a danada da falha mostrava um erro com "memcpy+0xd/0x110", eu imaginei que era falha de cópia de dados pra alguma endereço da memória RAM, ou seja, o pente de memória que comprei no #DX estava com problemas, o que denota a máxima de que, na dúvida, culpe o fornecedor Chinês mais próximo de você.

Passei os restantes dos dias buscando por mais reclamações sobre problemas de hibernação no Ubuntu 12.10 ou algo parecido, e... nada.  Comecei a desconfiar mesmo dos produtos chineses, a ponto de passar 2 dias rodando memtest pra verificar o estado da RAM, procedimento aliás que só causa expectativa seguida de frustração, e não tira o produto Chinês da mira de vilão da história.

Hoje, por um acaso muito grande, eu resolvi buscar pelo erro do bug, mas na verdade para buscar alguma ferramenta para bloquear o segmento de memória danificado.  Então busquei pela linha:

BUG: unable to handle kernel paging request at

E encontrei umas referências sobre problemas em... Sony Vaio!  Justamente a marca do meu laptop.  Coincidência?

Então resolvi buscar diretamente o endereço de memória do meu problema:

BUG: unable to handle kernel paging request at 0000000000ff1000

E não é que peguei um problema reportado e bem descrito no Launchpad, o sistema de reporte de bugs do Ubuntu? Eu nunca tinha encontrado referências a esse bug porque a descrição fala de problema de Sony Vaio (outro duh!).

[SONY VAIO VPCS12L9E] Suspend doesn't work after dist-upgrade to Quantal 12.10

Felizmente a pessoa que abriu o bug report fez uma bela descrição do problema e também de uma solução.  Apenas apliquei os seguintes passos para ter meu sistema funcionando corretamente:

sudo add-apt-repository ppa:shiba89/vaio-kernel
sudo apt-get update
sudo apt-get install linux-headers-generic sony-laptop-dkms

Com isso, no boot seguinte tive a comprovação de que meu laptop voltou à hibernar feito um bebê.  E com isso fecho 2012 sem pendências, ao menos pessoais, para 2013.

E que venha 2013!  Se sobrevivemos ao fim do mundo segundo os Maias, não é um problema de kernel que vai nos segurar!

memcontrold

Autor:
Data de criação:
Data de publicado:
Acessos: 2053

O calcanhar de Aquiles do Linux sempre foi o gerenciamento de memória.  Por mais memória que se tenha disponível, ele vorazmente sempre quer mais.  E nunca libera a memória livre.

E meus parcos 6 GB de memória do laptop tem sentido isso nesses últimos dias de 2012.   E verificável pelos gráficos do Munin, que mostra o pedido de 10 GB de memória pra usar.  Isso me faz pensar que talvez os Maias esteja certos.

 

 

Eu ainda não descobri qual programa (ou processo) está causando isso, e o kernel Linux não cuida de matar o processo comilão.

Então criei um pequeno daemon, em perl, para ficar lendo o /proc e matando os processos que mais consomem memória se a carga do sistema aumentar muito (atualmente marquei para load average maior de 10).

 

#! /usr/bin/perl

use POSIX;

$PROC = "/proc";
$MAXLOAD = 10;  #loadaverage
$SLEEPTIME = 1; #seconds

if (getuid() != 0) {
  print "Only root can run this program.\n";
  exit(1);
}

if (! -d $PROC) {
  print "Not possible to run.  System not running with $PROC directory\n";
  exit(1);
}

sub GetMem() {
  $pid_dir = $_[0];
  my $dir = $PROC."/".$pid_dir."/statm";
  open(MEM, $dir) or die "Error:$dir $!\n";
  @params = split(/ /, );
  close MEM;
  $memory = $params[0];

  return $memory;
}

sub GetPID() {
  my %MEM;
  opendir(PROC,$PROC) or die "Not possible to run.  System not running with $PROC directory\n";

  foreach $dir (readdir PROC) {
	# Just read higher processes
	# avoid init (1) or non-pid
	next if ($dir !~ m/^\d\d\d+/);
	$mem = &GetMem($dir);
	if ($mem) {
	  $MEM{$dir} = $mem;
	}
	
  }
  closedir PROC;

  return %MEM;
}

sub GetLoad() {
  open(LOAD,$PROC."/loadavg") or die "Impossible to detect load average by $PROC:$!\n";
  my $load = ;
  close LOAD;
  my @params = split(/ /, $load);

  return $params[0];
}

sub GetCommand() {
  my $pid = $_[0];
  open(CMD, $PROC."/".$pid."/cmdline") or die "Impossible to read the source command: $!\n";
  my $cmd = ;
  close CMD;

  return $cmd;
}

sub DaemonizeMe() {
  print "Starting to memory control daemon\n";
  POSIX::setsid or die "setsid: $!";
  my $pid = fork ();
  if ($pid < 0) {
	die "fork: $!";
  } elsif ($pid) {
	exit 0;
  }
  chdir "/";
  umask 0;
  foreach (0 .. (POSIX::sysconf (&POSIX::_SC_OPEN_MAX) || 1024)) { 
	POSIX::close $_; 
  }
  open (STDIN, "/dev/null");
  #open (STDERR, ">&STDOUT");
}

&DaemonizeMe();
my $mypid = getpid();
my %DEATHCOUNTER;

while (! $SIG{TERM}) {
  
  sleep($SLEEPTIME);
  my $load = &GetLoad();
  next if ($load < $MAXLOAD);
  my %MEM;
  %MEM = &GetPID();

  $higher_m = 0;
  $higher_pid = 0;

  foreach $k (sort keys %MEM) {
	next if ($k eq $mypid);
	$mem = $MEM{$k};
	if ($mem > $higher_m) {
	  $higher_m = $mem;
	  $higher_pid = $k;
	  $DEATHCOUNTER{$higher_pid}++;
	}
  }

  if ($DEATHCOUNTER{$higher_pid} >= 5) {
	print "Killing due higher memory usage: ".&GetCommand($higher_pid)." (".$higher_pid.") [".$higher_m." Bytes]\n";
	%DEATHCOUNTER;
  }
}

print "Exiting...";
exit(0);

Os Maias podiam até estar certos, mas isso não significa que precisamos ficar sentados olhando.

Data de criação:
Data de publicado:
Acessos: 2523

Já faz anos que compilo meus kernels e sistemas com a utilização do parâmetro "-j 8" ou "-j 12".  Esse parâmetro, passado ao GCC, faz uso de multithreads em máquinas com mais de um processador ou processador multicore, como esse Intel Core i3 que tenho no laptop.

Mas sempre usei esse parâmetro quase que como dogma, sem muita certeza de sua eficiência.  Aliás, com uma pequena idéia de eficiência já que, sem o uso do mesmo, o tempo de compilação era mais demorado.  Mas tudo muito de "sentimento", sem nenhuma comprovação.

Então, num desses dias sem muita coisa pra fazer (pequena metira: estava lotado de coisas pra terminar, mas decidi fazer isso pra limpar um pouco a mente), resolvi verificar essa compilação com dados mais concretos e monitoração dos resultados.  Fiz o seguinte programa em python pra ficar compilando um kernel que já estava configurado e que eu tinha certeza que compilava sem problemas, com as threads indo de 1 a 20:

#! /usr/bin/python
# make clean; time make-kpkg -j 4 --initrd kernel_image
import os
import time

#print time.time()
OUTPUT = "/tmp/kernel_results.csv"

FD = open(OUTPUT, "w")

for TH in xrange(1,21):
        print "Threads:", TH
        print "\tlimpando..."
        os.system("make clean")
        t_0 = time.time()
        os.system("make-kpkg -j " + str(TH) + " --initrd kernel_image")
        t_1 = time.time()
        total_time = t_1 - t_0
        msg = "Threads: %d in %0.2f s" %(TH, total_time)
        print msg
        FD.write(str(TH) + "," + str(total_time) + "\n")
        FD.flush()

Então deixei o sistema rodando.  Eu costumo usar o "make-kpkg", do pacote kernel package, que já gera para mim o pacote DEB para instalação.

Ao final, os resultados foram os seguintes:

A troca de contextos de processos realmente aumentou com o aumento de threads.  Por isso o sistema fica tão lento.

O sistema ficou com uso de CPU intenso, mas sem crescimento gradual (isso eu já achei estranho).

As interrupções de mudança de contexto também ficaram iguais, onde eu esperava um valor em degraus.

Mas a carga do sistema, load average, aumentou realmente em degrau, acompanhando a quantidade definida no "-j".  Isso era esperado e é sempre notado, pois o computador fica super lento.

Porém o melhor ficou pro final: a análise do tempo pela quantidade de threads.

O tempo diminuiu conforme a quantidade de threads que aumenta até... 3???  O processador Intel Core i3 é um multicore de 4 cores, eu esperava ao menos um melhor desempenho até 4 threads, mas dá pra ver bem claro que o sistema estabiliza em 3.

Ou seja, usando "-j 8" ou "-j 12" só serve para aumentar a carga da CPU, aumentando as trocas de contextos, mas não significam nem melhora nem otimização da compilação.  Pelo contrário.  Então o melhor é saber o máximo que a CPU realmente aguenta antes de aplicar cegamente parâmetros para *melhorar* o desempenho do sistema.  E monitorar os resultados!

Atualização: Sun Feb  3 20:34:35 BRST 2013

Conforme pedido do Erick Tostes, @ericktostes no twitter, estou incluindo o meu /proc/cpuinfo.

processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 37
model name      : Intel(R) Core(TM) i3 CPU       M 330  @ 2.13GHz
stepping        : 2
microcode       : 0x9
cpu MHz         : 933.000
cache size      : 3072 KB
physical id     : 0
siblings        : 4
core id         : 0
cpu cores       : 2
apicid          : 0
initial apicid  : 0
fpu             : yes
fpu_exception   : yes
cpuid level     : 11
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 
clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc 
arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni dtes64 monitor 
ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm arat dtherm tpr_shadow 
vnmi flexpriority ept vpid
bogomips        : 4255.62
clflush size    : 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

processor       : 1
vendor_id       : GenuineIntel
cpu family      : 6
model           : 37
model name      : Intel(R) Core(TM) i3 CPU       M 330  @ 2.13GHz
stepping        : 2
microcode       : 0x9
cpu MHz         : 933.000
cache size      : 3072 KB
physical id     : 0
siblings        : 4
core id         : 0
cpu cores       : 2
apicid          : 1
initial apicid  : 1
fpu             : yes
fpu_exception   : yes
cpuid level     : 11
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 
clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc 
arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni dtes64 monitor 
ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm arat dtherm tpr_shadow 
vnmi flexpriority ept vpid
bogomips        : 4255.62
clflush size    : 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

processor       : 2
vendor_id       : GenuineIntel
cpu family      : 6
model           : 37
model name      : Intel(R) Core(TM) i3 CPU       M 330  @ 2.13GHz
stepping        : 2
microcode       : 0x9
cpu MHz         : 933.000
cache size      : 3072 KB
physical id     : 0
siblings        : 4
core id         : 2
cpu cores       : 2
apicid          : 4
initial apicid  : 4
fpu             : yes
fpu_exception   : yes
cpuid level     : 11
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 
clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc 
arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni dtes64 monitor 
ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm arat dtherm tpr_shadow 
vnmi flexpriority ept vpid
bogomips        : 4255.62
clflush size    : 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

processor       : 3
vendor_id       : GenuineIntel
cpu family      : 6
model           : 37
model name      : Intel(R) Core(TM) i3 CPU       M 330  @ 2.13GHz
stepping        : 2
microcode       : 0x9
cpu MHz         : 933.000
cache size      : 3072 KB
physical id     : 0
siblings        : 4
core id         : 2
cpu cores       : 2
apicid          : 5
initial apicid  : 5
fpu             : yes
fpu_exception   : yes
cpuid level     : 11
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 
clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc 
arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni dtes64 monitor 
ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm arat dtherm tpr_shadow 
vnmi flexpriority ept vpid
bogomips        : 4255.62
clflush size    : 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

O pf-kernel

Autor:
Data de criação:
Data de publicado:
Acessos: 2550

Já faz tempo que estou querendo escrever um pouco sobre o pf-kernel e acho que finalmente chegou esse momento.  Talvez a idéia dramática de fatalidade, derivado do fato de que estou assistindo o filme 2012, tenha me levado a escrever sobre isso logo.

Sempre existiram variações do kernel do Linux, desde seu surgimento.  As versões de Andrew Morton eram famosas por incluir algumas vantagens como melhor preempção e gerenciamento de memória se comparado com o kernel padrão, por exemplo.  Mas isso era no passado.  Nos tempos atuais de Linux, alguns kernels modificados para melhoria de resposta em tempo real são os mais famosos, justamente por existir dentro de distribuições como Debian e Ubuntu, bastando usar o gerenciador de pacotes para instalar e testar.  Nesse panorama, sem muito alarde, surgiu um novo fork do kernel Linux: o pf-kernel.

Site do pf-kernel

pf-kernel no GITHUB

Apesar da associação de pf-kernel com o packetfilter dos BSDs, na verdade o pf é uma referência ao apelido do autor, post-factum.  O pf-kernel é um kernel padrão Linux modificado da seguinte forma:

  1. [m] atualizações do kernel padrão
  2. [t] BLD: técnica de distribuição de carga pro kernel Linux
  3. [w] BFS: Brain Fuck Scheduler - escalonador de baixa latência
  4. [m] BFQ: Budget Fair Queue I/O scheduler - escalonador de E/S
  5. [m] TuxOnIce - sistema de hibernação
  6. [m] UKSM - suporte à deduplicação de dados

A maioria são patches para melhorar o tempo de resposta do sistema (preempção), mas não somente com alteração no escalonador, mas por melhorias inclusive nas respostas de I/O, além de TuxOnIce, uma forma nova hibernar o Linux, com várias vantagens em relação ao sistema padrão, como o retorno mais rápido.  Infelizmente no meu caso tive problemas do TuxOnIce com o meu filesystem, XFS.  Mas de resto, gostei de usar o pf-3.2, ficando com uptime além de 100 dias graças a ele. Eu não conhecia o pf-kernel, só tinha ouvido falar por cima, mas uma sugestão no twitter, do @cleitonflima, me fez experimentar e gostar muito dessa árvore de kernel.  Posteriormente encontrei um artigo sobre o mesmo:

Fazendo o pinguim voar: o pf-kernel

Apesar da riqueza de dados sobre pf-kernel nesse artigo, não há tanta informação assim sobre o mesmo.  Então não consegui confirmar o que o artigo diz sobre os patches, além das informações que cada patch já traz.  Aliás as melhorias, no meu processador Intel Core I3, só foram percebidas com carga alta, ou seja, load average acima de 4.  Abaixo disso, que é o normal do sistema, não percebi nenhum ganho.  Mas com o sistema sobrecarregado, consegui continuar ouvido música sem interrupções, o que não acontece com o kernel padrão.

E fui brindado com um kernel mais estável que o kernel padrão também.  Tive problemas com o kernel 3.2.0, e com o pf-kernel-3.2.5, mas a versão pf-kernel-3.2.7 funcionou muito bem (com exceção do problema do filesystem XFS).  Agora estou criando coragem pra compilar uma versão mais recente do pf-kernel, que suporte mais de 100 dias de uptime, mas não acho que terei problemas.

Pra quem tem uma máquina mais antiga, da geração Core Duo ou até anterior, é bem provável que os benefícios do pf-kernel sejam mais bem notados.  Para agraciados donos de CPUs mais modernas, como a última geração dos Core-i7, talvez nem seja perceptível, mas é sempre interessante testar as alternativa ao kernel padrão e saber que elas existem.

Data de criação:
Data de publicado:
Acessos: 3134

E minha alegria realmente chegou ao fim nos 110 dias de uptime.  Dessa vez o culpado foi o filesystem, XFS, que começou a cuspir vários erros como esses:

 
XFS (sda1): xlog_space_left: head behind tail
  tail_cycle = 252, tail_bytes = 8731136
  GH   cycle = 252, GH   bytes = 8731128
XFS (sda1): xlog_space_left: head behind tail
  tail_cycle = 252, tail_bytes = 8731136
  GH   cycle = 252, GH   bytes = 8731128
XFS (sda8): xlog_space_left: head behind tail
  tail_cycle = 1212, tail_bytes = 8328704
  GH   cycle = 1212, GH   bytes = 8328696
XFS (sda8): xlog_space_left: head behind tail
  tail_cycle = 1212, tail_bytes = 8328704
  GH   cycle = 1212, GH   bytes = 8328696
XFS (sda8): xlog_space_left: head behind tail
  tail_cycle = 1212, tail_bytes = 8356864
  GH   cycle = 1212, GH   bytes = 8356856
XFS (sda8): xlog_space_left: head behind tail
  tail_cycle = 1212, tail_bytes = 8356864
  GH   cycle = 1212, GH   bytes = 8356856
XFS (dm-0): xlog_space_left: head behind tail
  tail_cycle = 350, tail_bytes = 158558208
  GH   cycle = 350, GH   bytes = 158558200
XFS (dm-0): xlog_space_left: head behind tail
  tail_cycle = 350, tail_bytes = 158558208
  GH   cycle = 350, GH   bytes = 158558200
XFS (sda1): xlog_space_left: head behind tail
  tail_cycle = 252, tail_bytes = 8787968
  GH   cycle = 252, GH   bytes = 8787960
 
Isso em todas as partições.  Tentei forçar um "init 1" pra single mode e "desmontar/montar" as partições, mas as mesmas não permitiam isso.  Como encontrei referências bem ruins sobre esse comportamente, dizendo que poderia levar à perda de dados, eu preferi fazer o reboot do sistema.
 
A lista da SGI, criadora do XFS, foi essencial pra decidir o que fazer.  Só espero que o problema não se repita nos meus próximos 100 dias de uptime.
 
Data de criação:
Data de publicado:
Acessos: 4846

11:55:20 up 100 days, 0 min, 43 users, load average: 1.22, 0.83, 0.84


Finalmente meu laptop, de uso diário e pessoal, quebrou a barreira dos 100 dias de uptime. E o que isso quer dizer?  Nada, e ao mesmo tempo, várias coisas. Mas significa que estou trabalhando sem interrupções por 100 dias.

Fazia tempo que eu não tinha um uptime maior que 30 dias, quanto mais de 100.  O problema não era específico, mas um conjunto deles.  O que mais afetava o tempo em que a máquina funcionava sem interrupções (leia-se travamentos) era o driver de vídeo Intel.  Invariavelmente o Xorg apresentava um crash por conta dos efeitos 3D do KDE com o plasma-desktop.  Tentei de tudo, inclusive desabilitar os efeitos e até mesmo parar de usar o KDE, mas o crash de xorg sempre me encontrava.

Contudo vários esforços ocorreram em várias frentes e paralelamente, como sempre acontece no mundo do software livre.  A equipe do Xorg melhorou o driver Intel, o KDE, com o lançamento do 4.7, criou uma forma de contornar esse crash, deixando o ambiente plasma muito mais estável e, por fim, a equipe de kernel trabalhou na melhoria do driver framebuffer e DRM pra Intel.

Esse conjunto de melhorias deram um resultado excelente, visível pelo tempo em que o laptop está funcionando sem parar.  E olhe que o uso é intenso.  Faço desde desenvolvimento de software até apresentações pra clientes, inclusive utilizando 2 monitores (em geral uma televisão).  Tive alguns problemas nesse percurso, como uma sobrecarga no xorg, que levou o KDE a cair, mas nada que um reinício do serviço gráfico não pudesse resolver, sem precisar rebootar o laptop.

Em geral tenho trabalhado de forma consistente, fechando e abrindo o laptop, sem reiniciar o trabalho que tinha parado anteriormente.  Isso garante um ganho de produtividade muito bom, pois já vejo em que ponto eu estava da última vez e continuo dali pra frente.  Nada de reabrir documentos e procurar onde foi a última linha editada, nada de reabrir ambientes de desenvolvimento, nada de reiniciar minhas conexões SSH pra máquinas em que trabalho via VPN, já que faço isso automaticamente via script, que só detectam a queda do link e reiniciam a conexão.  Fecho o laptop na sexta-feira e reabro na segunda, como se tivesse parado pra um café.

Então quando se vê um uptime alto, não estamos falando somente de tempo se desligar a máquina mas a produtividade que isso proporciona.  Claro que existe um lado egocêntrico de falar no tempo sem desligar ou sem reboot, que vem da cultura de sysadmin, onde o maior uptime significa (ou ao menos significava) um servidor bem ajustado e configurado, mas isso é quase insignificante em relação ao benefício do trabalho ininterrupto.

E você?  Já chegou aos 100 dias ou isso ainda é um fardo pra sua produtividade?

Data de criação:
Data de publicado:
Acessos: 5181

Hoje pela manhã (ou quase isso), fui surpreendido pelo mau funcionamento da minha placa de rede cabeada, uma placa gigabit.  Não é uma placa que eu tenha escolhido, pois faz parte do notebook, um Sony Vaio VPC-S110GB.

Como a placa não tem led de indicação de funcionamento, eu só consegui identificar que não estava operando pela mensagem abaixo:

root@shibboleet:~# dmesg | grep -i eth
[45263.845838] ADDRCONF(NETDEV_UP): eth0: link is not ready

Após algumas tentativas infrutíferas de colocar e tirar o cabo (acabei até quebro o clipezinho que segura o cabo), dei uma olhada como estava a camada de enlace ethernet.

root@shibboleet:~# mii-tool eth0
SIOCGMIIREG on eth0 failed: Input/output error
SIOCGMIIREG on eth0 failed: Input/output error
SIOCGMIIREG on eth0 failed: Input/output error
SIOCGMIIREG on eth0 failed: Input/output error
SIOCGMIIREG on eth0 failed: Input/output error
SIOCGMIIREG on eth0 failed: Input/output error
SIOCGMIIREG on eth0 failed: Input/output error
SIOCGMIIREG on eth0 failed: Input/output error
SIOCGMIIREG on eth0 failed: Input/output error
SIOCGMIIREG on eth0 failed: Input/output error
SIOCGMIIREG on eth0 failed: Input/output error
SIOCGMIIREG on eth0 failed: Input/output error
eth0: negotiated 1000baseT-HD flow-control, link ok

Esse "Input/output error" já me deu uma dica que algo tinha acontecido com o driver da placa.  Como estou usando um kernel-pf, e compilado por mim, esse tipo de erro pode mesmo surgir.  Claro que existe a possibilidade de ser um defeito da placa, mas prefiro acreditar que o erro é meu, pois esse eu consigo consertar.

TPL_COM_CONTENT_READ_MORELinux e problemas na placa de rede
Data de criação:
Data de publicado:
Acessos: 3216

Gosto do jogo UFOAI, de UFO Alien Invasion.  É um jogo de estratégia que joguei pela primeira vez nos tempos do DOS e do "Windows 3.11 for Workgroups".  Nessa época era um outro jogo, pago, e que se chamava X-Com Unknown Enemy, ou algo assim.  Com o avanço dos sistemas, computadores, e jogos, obviamente ficou obsoleto e esquecido.  Então alguns fãns resolveram fazer uma versão opensource do jogo, e claro, com esteróides. 

O jogo exige OpenGL pra rodar, pois usa massivamente o "quake engine" pra renderizar os ambientes.  E é fantástico, e difícil, pois tem uma inteligência artificial aprimorada, que faz com que seus soldados saiam correndo de medo no meio de algumas batalhas.

Fazia tempo que não jogava, mesmo porque jogo mais em console que no PC, mas essa semana resolvi brincar um pouco.  Eis que descubro um problema de OpenGL no meu laptop:

helio@shibboleet:~$ ufo +set vid_ref sdl

---- filesystem initialization -----
Adding game dir: /usr/share/games/ufoai/base
Added packfile /usr/share/games/ufoai/base/0base.pk3 (9 files)
Added packfile /usr/share/games/ufoai/base/0maps.pk3 (544 files)
Added packfile /usr/share/games/ufoai/base/0materials.pk3 (45 files)
Added packfile /usr/share/games/ufoai/base/0media.pk3 (10 files)
Added packfile /usr/share/games/ufoai/base/0models.pk3 (2015 files)
Added packfile /usr/share/games/ufoai/base/0music.pk3 (49 files)
Added packfile /usr/share/games/ufoai/base/0pics.pk3 (2114 files)
Added packfile /usr/share/games/ufoai/base/0shaders.pk3 (26 files)
Added packfile /usr/share/games/ufoai/base/0snd.pk3 (266 files)
Added packfile /usr/share/games/ufoai/base/0ufos.pk3 (97 files)
Adding game dir: ./base
Added packfile ./base/0base.pk3 (9 files)
Added packfile ./base/0maps.pk3 (544 files)
Added packfile ./base/0materials.pk3 (45 files)
Added packfile ./base/0media.pk3 (10 files)
Added packfile ./base/0models.pk3 (2015 files)
Added packfile ./base/0music.pk3 (49 files)
Added packfile ./base/0pics.pk3 (2114 files)
Added packfile ./base/0shaders.pk3 (26 files)
Added packfile ./base/0snd.pk3 (266 files)
Added packfile ./base/0ufos.pk3 (97 files)
Adding game dir: /home/helio/.ufoai/2.3.1/base
using /home/helio/.ufoai/2.3.1/base for writing
executing default.cfg
couldn't execute config.cfg

----- network initialization -------
libcurl/7.21.6 OpenSSL/1.0.0e zlib/1.2.3.4 libidn/1.22 librtmp/2.3 initialized.

------ server initialization -------
added 7 maps to the mapcycle

----- console initialization -------
Console initialized.

------- video initialization -------
SDL version: 1.2.14
I: desktop depth: 32bpp
I: video memory: 0
I: Available resolutions: 1366x1792 1366x768 1360x768 1024x768 800x600 640x480 (6)
I: video driver: x11
I: setting mode -1
I: set swap control to 0
X Error of failed request:  GLXUnsupportedPrivateRequest
  Major opcode of failed request:  155 (GLX)
  Minor opcode of failed request:  16 (X_GLXVendorPrivate)
  Serial number of failed request:  25
  Current serial number in output stream:  26

Tentei forçar o sistema a inicializar sem o uso de OpenGL, com o parâmetro "+set vid_ref sdl", mas nem isso resolveu.  Como não existe nada mais sagrado ao homem que seus jogos eletrônicos, resolvi consertar o problema.  Ou ao menos tentar.

TPL_COM_CONTENT_READ_MOREUFOAI, OpenGL e nvidia vs Intel
Data de criação:
Data de publicado:
Acessos: 3177

Não vou escrever sobre vídeos de pornografia ou de pessoas xingando, nada disso.  Vou falar de novo dos "padrões Microsoft".  Não é de hoje que a Microsoft cria aplicativos não padronizados e que fazem questão de não funcionar em outros sistemas além do Windows.

Num desses dias me deparei com um danado de um arquivo de vídeo, WMV, que não funcionava de jeito nenhum.


helio@shibboleet:tmp$ mplayer sound_of_music.wmv 
mplayer: Symbol `ff_codec_bmp_tags' has different size in shared object, consider re-linking
MPlayer SVN-r33713-4.6.1 (C) 2000-2011 MPlayer Team
mplayer: could not connect to socket
mplayer: No such file or directory
Failed to open LIRC support. You will not be able to use your remote control.

Playing sound_of_music.wmv.
ASF file format detected.
[asfheader] Video stream found, -vid 1
[asfheader] Audio stream found, -aid 2
VIDEO:  [WMV3]  352x264  24bpp  1000.000 fps  336.0 kbps (41.0 kbyte/s)
Load subtitles in ./
open: No such file or directory
[MGA] Couldn't open: /dev/mga_vid
open: No such file or directory
[MGA] Couldn't open: /dev/mga_vid
[VO_TDFXFB] Can't open /dev/fb0: Permission denied.
[VO_3DFX] Unable to open /dev/3dfx.
NVIDIA: could not open the device file /dev/nvidiactl (No such file or directory).
[vdpau] Error when calling vdp_device_create_x11: 1
==========================================================================
Opening video decoder: [dmo] DMO video codecs
DMO dll supports VO Optimizations 0 1
DMO dll might use previous sample when requested


MPlayer interrupted by signal 11 in module: init_video_codec
TPL_COM_CONTENT_READ_MORETocando uns WMV mal educados
Data de criação:
Data de publicado:
Acessos: 5920

Não tem nada mais chato que sistema lento.  Atualmente não dá pra aguentar um sistema que fica cortando a música que se está ouvindo só porque o Firefox consumiu 2 GB de memória, a máquina virtual no VirtualBox tá com mais 2 GB alocados e ainda tá compilando um kernel.

Pois é exatamente o que tem acontecido e muito em Linux.  Não sei de outras distribuições, mas especificamente em Ubuntu.

Como os patches de tempo real foram incluídos na árvore principal do kernel já faz algum tempo, isso deveria estar bem mais amenizado.  Fui em busca de informação sobre como ativar tal função e encontrei o comando "chrt" (change realtime talvez).

Lendo o manual do chrt, é possível ver uma gama de opções sem muitas explicações, nem comparativos de resultados.  Isso não ajuda muito na ampla adoção do mesmo.  Eu acabei fazendo alguns experimentos tanto em Intel 32 bits quanto em 64 e consegui um resultado supreendemente bom e bem fácil.  Apenas adicionei prioridade de tempo real ao processo init.

chrt -r -p 1 1

Esse comando adiciona a política de escalonamento SCHED_RR ao processo ID 1 (init) com prioridade 1. 

A política default do init é SCHED_OTHER, que de acordo com manual - SCHED_SETSCHEDULER(2) - significa:

SCHED_OTHER   política padrão de round-robin baseado em compartilhamento de tempo

SCHED_RR      política round-robin

Olhando mais a fundo o manual do escalonador, é possível ver que somente o SCHED_RR ativa a funcionalidade de tempo real.

Então basta adicionar esse comando no "/etc/rc.local" do Ubuntu/Debian para ter um sistema sem problemas de "travadinhas" quando sobrecarregado.  Eu fiquei mesmo surpreso em como foi fácil melhorar o desempenho do sistema e como isso não é incluído por padrão nos sistemas.


Data de criação:
Data de publicado:
Acessos: 4156

Faz alguns dias, comecei a ter o prazer de assistir os vídeos do YouTube em cor-de-rosa:

Principalmente no recente instalado Ubuntu 64 bits.  A princípio achei que era um dos tão mencionados problemas de flash em Linux 64, mas pude ver em alguns fóruns que isso tem afetado todos as versões de Linux pra Intel, tanto de 32 quanto 64 bits.

Consegui amenizar um pouco o problema com as dicas que encontrei aqui:

http://www.webupd8.org/2011/03/fix-pinkred-youtube-videos-bug-using.html

Mas o problema persiste.  Mais uma boa razão pra abandonar logo o flash, que é proprietário e depende unicamente da Adobe pra corrigir.

2017  helio.loureiro.eng.br   globbersthemes joomla templates