[FUG-BR] vm.pmap.shpgperproc

[Nilson]

2009/12/28 mateusgra <mateusgra at bol.com.br>:
>   Â
>  Valores Atuais.
>   vm.pmap.shpgperproc: 6.793
>   vm.pmap.pv_entry_max: 50.000.000
>   Li em uma lista que tem que colocar o options
PMAP_SHPGPERPROC=1024 no
>   conf e compilar o kernel novamente.

Se o seu limite de SHared PaGes PER PROCcess já está
em 6793 e o kernel tá berrando, como é que colocar 1024
vai resolver? Coloca uns 8k ou 16k. Depende da finalidade
pra qual você está usando essa quantidade absurda de
memória compartilhada.


>   Fiz isso em uma VM de teste e deu certo, mas queria entender porque
>   com  kern.ipc.shm_use_phys=1 o alerta "Approaching the limit on PV
>   entries, consider increasing either the vm.pmap.shpgperproc or the
>   vm.pmap.pv_entry_max sysctl" não aparece.

É por que cada vez que algum processo quer alocar memória,
o kernel tem que dar um endereço de memória pro programa:
"toma, esse é o endereço do bloco q tu me pediu".
Só que cada arquitetura de computador (o funcionamento
físico mesmo) é de um jeito, uns melhores outros piores,
então o pessoal inventou o mapa PV (Physical to Virtual),
assim o kernel entrega um endereço VIRTUAL pro programa
e mapeia na sua PMAP onde fica físicamente aquela
informação. Isso tem um camalhaço de vantagens pro
kernel, por que ele pode ficar mudando tua informação
de lugar sempre que ele precisar ou quiser, e aquele
endereço virtual que ele deu lá no começo continua
o mesmo. Entendeu até aqui?

Isso tudo era sobre memória "comum", dai um pessoal
que não tinha umas ideias muito boas de programação
achou q toda essa babaquisse de restrições de memória
no unix era uma puta enchessão de saco pra programar
coisas complexas, então inventaram um lixão chamado
SHARED MEMORY. Quando um processo aloca memória
compartilhada, o kernel também entrega um endereço
virtual, e quando outro processo quer acessar aquele
MESMO PEDAÇO de memória compartilhada, o kernel
entrega OUTRO ENDEREÇO virtual que é só mais uma
entrada na tabela de pvs (a tal pv_entry) que aponta pro
mesmo lugar físico, só que tem outras propriedades, como
outro dono, ou somente leitura, etc...

Então quando você usa aquele "shm_use_phys" você
está dizendo pro kernel parar com essa "baboseira" de
virtual, por que o software que você quer rodar é POWER,
é a coisa MAIS IMPORTANTE do computador, e que
SHM de agora em diante tem que ser sempre PHYSICAL.

Assim, não tem mais entradas PV pra todo bendito
processo que quer compartilhar aquele pedaço, o kernel
já diz direto fisicamente onde fica e que se dane...

Isso tem a vantagem de acabar com esse overhead
(penso que é pequeno...) do gerenciador de memória,
e como desvantagem a limitação da quantidade de
restrições que podem ser impostas a essas páginas,
e a PIOR de todas é que essas páginas compartilhadas
JAMAIS poderão ser mandadas pra memória virtual (SWAP).

Vira memória presa pra sempre.

>   O que siginifica o PMAP_SHPGPERPROC ?

Significam PMAP = Physical MAP (Mapa da memória física
do computador), e o SHPGPERPROC é a quantidade máxima
de páginas de memória compartilhada que UM único processo
pode ser dono.

> Não tem como mudar ele sem ter
>   que recompilar o kernel ?
>   Ja coloquei vm.pmap.shpgperproc: 12.000 e vm.pmap.pv_entry_max:
>   80.000.000, mesmo a mensagem continua.

No /boot/loader.conf você deve poder mudar esses valores
tranquilamente, só tendo que rebootar pra entrarem em efeito.

Acho que fiz a caca de mandar um email pela metade,
não sei se foi, mas o que vale é esse. Malditos atalhos de
teclado do gmail.

E pra finalizar, que mal lhe pergunte: que software faminto
por memória compartilhada tas rodando? PostgreSQL?

---
Nilson