ASM51

Pergunta ao Marcelo Samsoriuk, polesapart ou outras feras que saibam do assunto.

Tenho uma Beagleboard e to com umas duvidas que sao mais relacionadas a programacao e configuracao de SO. Na verdade, nao sei muita coisa de SO. O pouco que aprendi foi com um professor da faculdade que, respondendo a minha pergunta, disse que o algoritmo de gerenciamento da memoria do windows e do linux sao quase identicos. Pela diferenca de performance entre os dois, acredito que isso nao seja verdade. Tenho tentado aprender, mas com o tanto de coisas pra fazer, isso deixou de ser prioridade. Sera que alguem poderia me dar uma pincelada de como funciona essas coisas e mais ou menos onde procurar? O Marcelo uma vez mencionou o livro do Minix, mas ele eh um bocado grande e, por falta de tempo (e nao preguica), vou ter que deixar pra ler ele depois, quando isso passar a ser uma prioridade.

1) Peguei essa imagem pra instalar Ubuntu na Beagleboard. Ela faz o SD card automatico e depois ainda expande o cartao. Uma beleza. So que o hub usb nem acende a luz. Parece que ele nem "ativado" eh. Tem alguma configuracao na inicializacao do linux pra mudar para isso?

https://wiki.ubuntu.com/ARM/OMAPMaverickInstall

O outro cartao, com outra distro de linux, tem sido usada muito bem ate agora. Ela ativa sem problemas o usb hub. Mas quando essa distro (que funciona, nao o ubuntu) trava, tem que ser reiniciada 2 vezes para o hub voltar a funcionar.

2) Tem sido utilizado ate entao mmap no /dev/mem para acessar registradores de configuracao do processador (DMA, SPI, Clocks, etc.). Sim, eu sei que essa nao eh uma boa opcao. Ainda mais porque o programa tem que funcionar como root. Tem alguma outra forma de acessar esses registradores de outra maneira? Comecei a ler um livro de device drivers para linux que explica o acesso por read/write e ioctl. O problema eh saber quais os "comandos" a serem dados via ioctl. Alguem tem um exemplo de como utilizar esse metodo para acessar registradores? Quais sao os request code numbers e onde estao normalmente os header files com os request code numbers? Com esse tipo de acesso, eu poderia executar o programa sem ser root?

3) O Marcelo tambem mencionou uma vez o acesso ao kernel via interface de rede, que eh mais rapido e eh meio que o modo mais eficiente. Alguem tem um exemplo de como funciona isso ou sabe como posso procurar sobre isso (palavras chaves, etc.)?


Obrigado a quem puder ajudar.

albertorcneto escreveu:Na verdade, nao sei muita coisa de SO. O pouco que aprendi foi com um professor da faculdade que, respondendo a minha pergunta, disse que o algoritmo de gerenciamento da memoria do windows e do linux sao quase identicos. Pela diferenca de performance entre os dois, acredito que isso nao seja verdade. Tenho tentado aprender, mas com o tanto de coisas pra fazer, isso deixou de ser prioridade. Sera que alguem poderia me dar uma pincelada de como funciona essas coisas e mais ou menos onde procurar?

na essencia sao iguais sim: ambos utilizam a unidade de gerenciamento de memoria (MMU) do processador. atraves da MMU a memoria eh paginada e com torna-se possivel transformar paginas ordenadas randomicamente em areas lineares. alem disso, a MMU permite a implementacao de maquina virtual e memoria virtual.

mas ateh onde eu conheco, a implementacao eh totalmente diferente. o conceito essencial nos unix eh que a memoria eh uma extensao do filesystem (embora o filesystem nao necessariamente precise ser em um disco fisico). entao quando ele boota, a primeira coisa a fazer eh um mmap do init. conforme o init executa, paginas sao puxadas do filesystem e mapeadas na memoria. a medida que o init roda, ele forka em outros processos, que por sua vez mapeiam e rodam outros binarios com mmap. neste caso, a carga eh sempre sob demanda. se uma parte do executavel nao for utilizada, ela nao eh transferida para a memoria.

o conceito de fork eh interessante quando vc entende como um web, ftp ou smtp server funcionam: um processo principal esta ouvindo uma porta tcp e entao chega uma conexao. o processo entao forka, de modo que o processo original volta a ouvir a porta tcp e o processo forkado trata a conexao.

inicialmente os processos sao identicos, o que significa que vc pode atender milhares de conexoes e ainda assim vai estar usando as mesmas areas de memoria. as paginas compartilhadas sao marcadas para gerar excessoes de escrita. assim, quando dois processos diferentes tentam escrever uma variavel, uma excessao ocorre e a pagina eh duplicada, um mecanismo conhecido como copy on write.

na maioria dos unix existem particoes entre memoria principal e caches, enquanto no linux eh tudo unificado, de modo que qq pagina livre pode ser usada como cache.

ateh onde eu sei, conceitos de mmap e fork nao existem no windows.

O Marcelo uma vez mencionou o livro do Minix, mas ele eh um bocado grande e, por falta de tempo (e nao preguica), vou ter que deixar pra ler ele depois, quando isso passar a ser uma prioridade.

procure as edicoes antigas. o original em ingles, por exemplo, eh bem mais compacto. e claro, metade do livro eh codigo fonte do minix, que obviamente eh apenas para referencia e vc nao precisa ler!

dar uma lida no K&R ANSI C tambem eh uma boa!

2) Tem sido utilizado ate entao mmap no /dev/mem para acessar registradores de configuracao do processador (DMA, SPI, Clocks, etc.). Sim, eu sei que essa nao eh uma boa opcao. Ainda mais porque o programa tem que funcionar como root. Tem alguma outra forma de acessar esses registradores de outra maneira? Comecei a ler um livro de device drivers para linux que explica o acesso por read/write e ioctl. O problema eh saber quais os "comandos" a serem dados via ioctl. Alguem tem um exemplo de como utilizar esse metodo para acessar registradores? Quais sao os request code numbers e onde estao normalmente os header files com os request code numbers? Com esse tipo de acesso, eu poderia executar o programa sem ser root?

alem de read/write e ioctl vc pode fazer uma interface via /proc, que eh uma interface de muito alto nivel e permite vc ler usando cat e escrever usando echo.

http://www.ibm.com/developerworks/linux ... -proc.html

via read/write ou ioctl vc tem algo mais classico. mas nao quer dizer tb que vc nao possa usar mmap em uma area em particular apenas. tem varias opcoes.

3) O Marcelo tambem mencionou uma vez o acesso ao kernel via interface de rede, que eh mais rapido e eh meio que o modo mais eficiente. Alguem tem um exemplo de como funciona isso ou sabe como posso procurar sobre isso (palavras chaves, etc.)?

entao, quando eu estava fazendo pesquisas com o QMC de um MPC860 de 50MHz e comecei a fazer um device driver tradicional no /dev de onde uma aplicacao poderia ler e escrever em 32 canais de audio PCM de 64kbps cada. porem, logo no inicio o powerpc arriou feio e eu nao entendi muito bem o motivo. ocorre que o kernel precisava fazer um memcpy entre kernel e user space a cada write/read no /dev do pcm. a informacao de audio era entao concatenada com o header RTP e enviada por um socket UDP, onde eh de se esperar existe outro memcpy entre kernel e user space. assim, para os 32 canais de audio bi-direcionais, o powerpc precisava fazer 2 memcpy na ida e 2 memcpy na volta.

a minha solucao foi suprimir estes memcpy, de modo que o trafego das interfaces PCM era trocado diretamente com o socket de rede. para isso parti de um device driver de ethernet:

http://joshua.raleigh.nc.us/docs/linux- ... 05403.html

a jogada eh que ele programa o DMA da ethernet para jogar o trafego diretamente em um negocio chamado sk_buff, que eh um buffer multi-protocolo no kernel. neste buffer multi-protocolo eu apenas uso o payload do RTP, sem fazer memcpy nem nada, de modo que o DMA de uma SCC puxa isso e envia como trafego PCM. a chegada eh similar, o DMA escreve diretamente na area de payload RTP de um sk_buff e depois o proprio device driver cria o header RTP, UDP e IP para encaminhar para o kernel.

e isso significa que tudo que a aplicacao deveria fazer esta no proprio kernel. o resultado eh que um ifconfig mostra varias interfaces rtp ao inves de eth e eu configuro um IP diferente para cada interface RTP. isso tem seu lado bom e ruim... na verdade para o RTP funcionar, eh necessario configuracoes complementares, que eu faco via /proc.

eu dei uma pesquisada e uma forma similar de interface eh usada por versoes mais avancadas da libcap que funcionam com mmap, ou seja, o trafego IP chega direto das interfaces de rede via DMA em sk_buffs e vc tem acesso via mmap, evitando memcpy entre kernel e user space. mas eh obvio que isso tudo soh funciona para dispositivos network centric, onde a ideia eh eliminar totalmente memcpy e fazer tudo via DMA.

O pessoal apelida esta técnica (dispensar memcpy de um lado para outro) de "Zero-Copy", ou seja, sem cópias.

Isto funciona maravilhosamente bem quando você tem DMA. Numa aplicação que estou desenvolvendo, a cpu fica em modo low-power 99,9% do tempo e a DMA copia frames ethernet pra memória, quando necessário (o driver ethernet tem um filtro que descarta boa parte dos pacotes que não são de interesse, de modo que nem é preciso tratá-los). A cpu acorda, faz o que tem que fazer (altera uns bytes no cabeçalho, e reprograma o dma do destino, ou seja, na verdade ela não faz quase nada), e dorme.