Eu li hoje no Phoronix que existe um patch de 200 linhas no Linux Kernel que melhora drasticamente a capacidade de resposta da área de trabalho.
Como os usuários do Ubuntu conseguem isso de uma maneira que é suportada?
Eu li hoje no Phoronix que existe um patch de 200 linhas no Linux Kernel que melhora drasticamente a capacidade de resposta da área de trabalho.
Como os usuários do Ubuntu conseguem isso de uma maneira que é suportada?
Respostas:
A discussão sobre esse patch específico ocorreu na lista de discussão da equipe do kernel do Ubuntu:
https://lists.ubuntu.com/archives/kernel-team/2010-November/013498.html
Mas deixe-me tentar elaborar ainda mais genericamente a melhor maneira de qualquer patch entrar no kernel do Ubuntu ...
Primeiro, é a política preferida da Equipe do Kernel do Ubuntu que os patches sejam enviados e aceitos antes da entrada no kernel do Ubuntu. É um grande fardo de manutenção para a Equipe do Kernel do Ubuntu ter que manter as correções de árvores. Além disso, se o patch beneficiará toda a Comunidade do Kernel, ele deverá ir para o fluxo primeiro.
Depois que o patch for aceito, ele finalmente entrará no kernel do Ubuntu automaticamente. Uma solicitação de seleção ou extração de cereja também pode ser feita, se desejar, consulte a página KernelPatches para obter mais informações.
Se o patch precisar ser aplicado como uma SRU ( atualização estável da versão ) a uma versão anterior do Ubuntu, é melhor aceitar o patch na árvore 2.6.xy estável a montante correspondente. Como parte de nosso processo normal de SRU do kernel, continuamente nos atualizamos para o kernel estável upstream mais recente. Assim, novamente obteríamos o patch automaticamente.
Acabei de ler o tópico lkml e espero poder oferecer algumas informações - embora não sobre a introdução do patch no Ubuntu. Como diz um post na lista vinculada do Ubuntu, provavelmente estará na 2.6.38 de qualquer maneira.
O patch agrupa automaticamente o processo com base em TTYs. Há muita discussão / argumento no lkml que diz que isso significa que não é relevante para o uso típico da área de trabalho - que não faz diferença para aplicativos interativos. Os casos de teste são todos baseados em "iniciar uma tarefa intensiva da CPU a partir de um terminal e examinar a capacidade de resposta de outra tarefa". Então, compile um kernel e tente assistir a um vídeo, por exemplo.
Isso não quer dizer que não seja bom, mas as manchetes gerais do tipo "área de trabalho melhorada em uma ordem de magnitude" podem ser enganosas se você nunca executar tarefas intensivas de CPU conectadas a um TTY. Eu poderia estar errado, é claro!
Houve algumas menções de maneiras de obter um resultado muito semelhante, adicionando aos seus scripts bash e permitindo a todos os usuários criar cgroups. Isso só funcionará se os kernels atuais do Ubuntu tiverem o cgroups ativado. As postagens relevantes são:
Obviamente, isso não está respondendo à pergunta, mas poderia ser usado para determinar se o patch é tão mágico quanto se esperava.
Como os usuários do Ubuntu conseguem isso de uma maneira que é suportada ?
Ênfase minha. A única maneira de obtê-lo de uma maneira suportada é aguardando o Ubuntu inseri-lo no kernel do Ubuntu. Como isso realmente está chegando à lista de discussão do kernel, é recente ao ponto em que todos os testes são bastante anedóticos e eu imagino que levará algum tempo até que esteja pronto para ser implantado em massa.
Em algum lugar entre o próximo lançamento e um longo período de tempo, seria o meu palpite inculto.
Mas se você é um menino grande (ou menina) e pode lidar com um kernel quebrado se algo der errado (ou seja, você sabe como usar o grub), pode corrigir e compilar seu próprio kernel.
Faça o download de um patch. Existem versões diferentes, mas a melhor por si só foi postada abaixo por outro usuário: http://pavlinux.ru/krnl/sched_autogroup-2.6.36.patch.bz2
Faça o download da fonte do kernel para a versão que seu patch está almejado. Neste caso 2.6.36. Você pode obter fontes do kernel vanilla (originais, não modificadas pela equipe do kernel do Ubuntu) no kernel.org e extraí-lo.
Salve o patch em algum lugar e aplique- cdo entrando no diretório de origem do kernel e executando: patch -p1 < /path/to/patch(você precisa do patchpacote para isso ... O que eu acho que vem como parte build-essentialse não estiver instalado por padrão)
E então continue com o restante do processo de construção "antiquado" ... Eu realmente não me incomodaria com os métodos mais novos, pois eles visam fontes de kernel sancionadas pelo Ubuntu / Debian ... Além disso, a maneira antiga parece mais fácil ( para mim).
Construir kernels não é difícil, mas você pode estragar tudo se se afastar muito do caminho aceito. E você não receberá suporte oficial se as coisas derem errado.
Como alternativa, há cada vez mais kernels surgindo com o patch incorporado (ou pelo menos na árvore de origem, aguardando o próximo lançamento).
Nota: esses dois kernels (e provavelmente outros também) se desviam da maneira do Ubuntu de fazer kernels um pouco. Você pode descobrir (como eu fiz quando mudei para o Liquorix) que o escalonamento da frequência da CPU para de funcionar ou a suspensão fica interrompida. Geralmente, existem correções e soluções alternativas, mas é provável que você não obtenha suporte do AskUbuntu ou do restante da comunidade Ubuntu, pois não podemos verificar todos os kernel disponíveis.
Você pode usar um simples "hack" publicado por um desenvolvedor RedHat em uma lista de discussão, que não requer a correção do kernel para obter a mesma coisa. Leia aqui: alternativa ao "patch de 200 linhas do kernel que faz maravilhas", que você pode usar imediatamente
A partir de 18/01/2011, o Linux 2.6.38-rc1 inclui o referido patch.
Veja as notícias relacionadas à Phoronix e a publicação de Linus .
Desde 29/01/2011, o Natty Narwhal constrói diariamente o Linux 2.6.38.
Portanto, atualmente existem duas soluções: