Linux Kernel's thread

diutsu

Portugal@Home Member
Já é tempo de estarmos todos actualizados. Fica aqui a thread para discussão das kernel's do linux.
___________

Lançamento kernel 3.3
Linux 3.3 has been released (official announcement) on 18 Mar 2012.
Summary: This release features as the most important change the merge of kernel code from the Android project. But there is more, it also includes support for a new architecture (TI C6X), much improved balancing and the ability to restripe between different RAID profiles in Btrfs, and several network improvements: a virtual switch implementation (Open vSwitch) designed for virtualization scenarios, a faster and more scalable alternative to the "bonding" driver, a configurable limit to the transmission queue of the network devices to fight bufferbloat, a network priority control group and per-cgroup TCP buffer limits. There are also many small features and new drivers and fixes are also available.

  1. Prominent features in Linux 3.3
    1. Android merge
    2. Btrfs: restriping between different RAID levels, improved balancing, improved debugging tools
    3. Open vSwitch
    4. Better bonding of network interfaces: teaming
    5. Bufferbloat fighting: Byte queue limits
    6. Per-cgroup TCP buffer limits
    7. Network priority control group
    8. Better Ext4 online resizing
    9. New architecture: TI C6X
    10. EFI boot support
  2. Driver and architecture-specific changes
  3. Various core changes
  4. Memory Management
  5. File systems
  6. Networking
  7. Virtualization
  8. Crypto
  9. Security
  10. Tracing/profiling
 
Obrigado!

Já li que compilar um kernel a partir da source para o nosso pc é uma forma de optimizar o sistema para o nosso hardware mas já experimentei e não achei diferenças de performance, isto em Ubuntu 10.04 LTS, com o kernel 3.2.
Já alguém teve boas experiências com isso? Seguiu algum howto?

Obrigado
 
Hoje em dia, num pc, com os recursos que tem, provavelmente não se nota grande diferença entre um stock kernel e um kernel compilado. Muitas vezes também se perde suporte se não se usar o kernel stock da distribuíção.
Noutros dispositivos, embedded, supercomputadores, etc, as coisas mudam bastante.

Pessoalmente, não compilo o kernel. Uso sempre a última versão, não é stock, mas não sou eu a compilar. Ando no 3.2.10.

Quem quizer optimizar o kernel para um certo sistema, acho que o localmodconfig, como target do make, é um bom começo.

http://thread.gmane.org/gmane.linux.kbuild.devel/3750

Quanto à versão 3.3, não tem nada que ache importante para mim.
 
Já li que compilar um kernel a partir da source para o nosso pc é uma forma de optimizar o sistema para o nosso hardware mas já experimentei e não achei diferenças de performance, isto em Ubuntu 10.04 LTS, com o kernel 3.2.

Não tens qualquer necessidade de recompilar um kernel, e não te traz beneficios nenhuns faze-lo pelo contrário, podes encontrar regressões em user space e não ser capaz de as resolver, e eventualmente poderás mesmo destroçar com o sistema. As optimizações feitas normalmente dependem de modificações de código ou de utilizações especificas, por exemplo em routers que teem um espaço limitado e precisas de uma imagem de initrd mais pequena que num PC.

Dou-te um exemplo simples... Dizem (fonte: Phoronix) que existem melhoramentos de performance de 30% no kernel 3.3 para as placas Intel... Não te vale de muito compilar um 3.3 porque apesar de ficares com um driver mais recente, para tirares vantagem dele vais ter que fazer update também do Mesa, e depois de fazeres o update ao Mesa (que te vai partir a ABI) vais ter que fazer rebuild de tudo o que linka contra o Mesa. Vais ter que eventualmente fazer update também ao Xorg (quer por linkar contra o Mesa quer por necessitar de codigo mais recente)... Por outras palavras, vais ter que fazer rebuild a mais de metade da distribuição para teres os tais 30%... O kernel em si é irrelevante num caso como esse pois um driver 3D depende de outros componentes.

Tú e 99% dos utilizadores vão chegar exactamente à mesma conclusão, não vale a pena andar a recompilar kernels (há 10/15 anos atrás faria alguma diferença, hoje nao).



Já alguém teve boas experiências com isso? Seguiu algum howto?

Existem HOWTO's para compilar o kernel, nao para optimizações porque as mesmas dependem sempre dos fins a que estão destinadas... e normalmente envolvem sempre mexer em codigo, as coisas não são tão lineares... Se fosse fácil os developers de kernel não eram pagos a peso de ouro e havia possivelmente developers a pontapé, coisa que não há hoje em dia devido à complexidade e padroes necessários para o kernel.
 
Ketheriel , eu concordo perfeitamente que actualmente para a grande maioria dos casos não é necessário compilar o kernel , mas diz isso a um gentoo user :)
 
Ketheriel , eu concordo perfeitamente que actualmente para a grande maioria dos casos não é necessário compilar o kernel , mas diz isso a um gentoo user :)
E eu que estava a tentar abster-me de comentar sobre isso aqui... :P

No Gentoo não dá para fugir a isso, pelo que sei pelo menos, há montes de versões no repositório, mas nada de binários.
Mas também não é coisa que me incomode, por um lado simplifica a coisa, é plain simple, não há cá initrd/initramfs, e até há pouco tempo nem usáva módulos, mas com coisas como o Virtualbox têm que ser...
make oldconfig, make, esperar 2 minutos, cp..., vim ...grub.conf, profit. É tão simples que até podia fazer um script para fazer isto tudo automáticamente. :P

Depois se usar a versão hardened é útil para configurar o grsec, pax e tal, mas isso já é outra história.

Há alguma vantagem para o sistema? Se calhar não (mas um sistema sem suporte de módulos seria mais seguro). Há alguma vantagem para mim? Acho que sim. É daquelas coisas que depois de ficar habituado o "normal" é que se estranha, portanto estou bem assim.
 
Aparicio:

Isso é uma das features do Gentoo, portanto quem instala Gentoo à partida tem alguma necessidade ou preferencia tipo de feature... Quanto ao kernel ser modular ou monolitico, isso depende das pessoas e sinceramente não vejo porque é que um kernel é mais seguro por ser monolitico (o que levanta outras questões), um exemplo simples... Como é que fazes num kernel monolitico para utilizar modulos por exemplo de storages que te distribuem o driver em formato binário pré-compilado (do qual nao tens a source)? Voltamos à historia das decisões dificeis e das necessidades de cada um.

O objectivo do meu post era alertar as pessoas para que por vezes compilar um kernel nao basta é preciso fazer a integração no sistema para tirar beneficio das features que veem no changelog, e utilizei um exemplo simples (driver intel) para o demonstrar.
 
Por isso é que referi o Virtualbox como exemplo, em que é preciso instalar módulos no host para que a coisa funcione bem, ou então por ter gráficas ati ou nvidia, mas no meu portátil é monolítico graças a ter uma gráfica intel.

Podes dizer que em termos de segurança não é muito relevante, mas não deixa de ser uma medida adicional como muitas outras coisas, sem suporte para módulos, não há hipótese de meter código maligno a correr no kernel space sem reiniciar a máquina, a não ser através de alguma falha de segurança conhecida claro.

Quanto ao aproveitar novas features, se têm que o compilar manualmente para usar a última versão em distros binárias, é um "problema" dessa distro. Têm rolling-releases como o Arch onde têm acesso quase imediato ao pacote do último kernel.
 
Curiosidade, existe algum site bem conhecido/aceite que tenha as changelogs relevantes/features adicionais destas versões de kernel? Gostava de ler sobre o que fizeram e pretendem fazer.
 
An Overview Of The Linux 3.14 Kernel Features

With yesterday's release of the Linux 3.14-rc1, here's a look at the top features that were merged for introduction in the Linux 3.14 kernel.

The mentioned features are what I've found most interesting about this next major kernel release to date based upon the dozens of articles I've already authored on Phoronix about Linux 3.14, my testing already of 3.14 development code on multiple systems, analytics via Anzwix, etc.

- Nouveau has new NVIDIA GPU support although it's still missing any meaningful re-clocking / power management support thus leaving its performance in an awful state for modern GPUs.

- Intel Broadwell graphics support is in good shape but more changes are coming in Linux 3.15. On a related note is also Broadwell audio support.

- Big VMware SVGA2 graphics driver changes in preparation for a new virtual GPU in its virtualization software.

- NVIDIA Tegra PRIME support although the Tegra K1 Nouveau support is coming for a future kernel release.

- Radeon DPM improvements and other fixes for the open-source AMD driver. RadeonSI UVD support now also works properly.

- AMD Cryptographic Coprocessor support under Linux via a new driver. This is important now that AMD announced its first 64-bit ARM server SoC.

- Generic CPU Boost.

- F2FS performance improvements for the Flash-Friendly File-System.

- New features and performance improvements for Btrfs.

- Kernfs was born out of sysfs.

- Xen PVH support for new Xen virtualization possibilities on modern Intel/AMD hardware.

- SCHED_DEADLINE finally made it into the mainline Linux kernel.

- BCache and blk-mq updates.

- Support for MIPS latest CPU core on Linux.

- Xtensa SMP support.

- TCP Auto Corking is a new networking feature found in Linux 3.14.

http://www.phoronix.com/scan.php?page=news_item&px=MTU5MDc

PS: já está disponível a RC2 do Kernel 3.14
 
Linux 3.14 has been released on Sun, 30 Mar 2014.

Summary: This release includes the deadline task scheduling policy for real-time tasks, a memory compression mechanism is now considered stable, a port of the locking validator to userspace, ability to store properties such as compression for each inode in Btrfs, trigger support for tracing events, improvements to userspace probing, kernel address space randomization, TCP automatic coalescing of certain kinds of connections, a new network packet scheduler to fight bufferbloat, new drivers and many other small improvements.
http://kernelnewbies.org/Linux_3.14
 
Features That Landed So Far For The Linux 3.15 Kernel

For those not keeping up to date on all of the Phoronix articles covering the Linux 3.15 kernel changes that landed in the past week, here's a recap of the changes that were merged so far half-way through the Linux 3.15 merge window.

- EFI mixed mode support to allow 64-bit Linux kernels to be booted from 32-bit system UEFI firmwares.

- AVX-512 instruction support for future Intel processors.

- AHCI libata improvements.

- Scheduler improvements.

- The mainline Linux kernel can almost be exploited for better performance through link-time optimization support for the kernel.

- Performance and bug-fixes for the Btrfs file-system.

- Many audio/sound improvements.

- ACPI and power management improvements, particularly better support for new hardware and ACPI improvements.

- Support was dropped for old x86 platforms.

- Kernfs is in better shape for other subsystems wishing to utilize this sysfs-derived code.

- Better Windows guest support for KVM virtualization.

- New input device support for the Linux 3.15 kernel, including Sony's DualShock 4 controller for the PlayStation 4.

- Better write performance with the FUSE file-systems in user-space.

- Intel RDSEED support for better randomness.

- EXT4 and XFS file-system updates.

- New media/V4L2 drivers.

- ARM SoC updates.

There's still several more days left to the Linux 3.15 merge window before Linux 3.15-rc1 is declared, including the DRM pull and other interesting merges, so stay tuned for the latest Linux kernel updates on Phoronix.

http://www.phoronix.com/scan.php?page=news_item&px=MTY1NzI
 
The Linux 3.16 Kernel Has Been Released

As anticipated, the Linux 3.16 kernel has been released this Sunday afternoon.

With nothing too exciting having been found or fixed since Linux 3.16-rc7 last Sunday, Linus Torvalds went ahead and issued Linux 3.16 final. If you're not familiar with Linux 3.16, read this morning's article about the best features of Linux 3.16 along with our many other Linux 3.16 kernel articles.

The codename for Linux 3.16 remains "Shuffling Zombie Juror", which has remained the codename since Linux 3.14-rc1. The 3.16 release announcement can be read in the Indiana archives.

Now to look forward to the Linux 3.17 merge window... Due to the Linux Kernel Summit and LinuxCon along with other Linux Foundation events taking place in Chicago later this month, Linus may slightly rework (or delay the closing of) the 3.17 merge window by a few days but he isn't yet sure how the merge window will ultimately play out due to the kernel developers heading to Chicago.

http://www.phoronix.com/scan.php?page=news_item&px=MTc1NDc


The Best Features Of Linux 3.16

- Samsung Exynos multi-platform support so that the Samsung ARM SoC kernel support is on-par with many other ARM SoCs and the ability to have a single kernel image support multiple ARM devices.

- Better upstream Jetson TK1 ARM development platform support.

- Broadwell support within Intel's P-State driver.

- Dell free-fall driver support to see if your Latitude laptop is falling.

- A new Synaptics input driver.

- Blk-mq is nearly feature complete as the multi-queue block layer implementation.

- For those still with an old Nokia N900 smart-phone, the modem is now supported by the mainline Linux kernel.

- Initial GK20A support as the NVIDIA Kepler-based GPU within the Tegra K1 SoC. The ARM hardware support in general has improved a fair amount with this new kernel.

- Nouveau support for Kepler GPU re-clocking albeit the support varies and there's more improvements to be made.

- Intel Cherryview support for the upcoming Intel Atom SoC succeeding Bay Trail / Valley View graphics.

- AMD Radeon graphics are faster with DRM improvements made in this latest kernel release.

http://www.phoronix.com/scan.php?page=news_item&px=MTc1NDM
 
Back
Topo