Най-интересните промени са:

1. Прозрачно разпределение на входящия мрежов трафик между процесорите
   Мрежовите карти са подобрили скоростта си на приемане до такава степен, че вече е трудно за един съвременен процесор да се справи. Две нови подобрения, внесени от Google, се опитват да разпределят натоварването на мрежовият трафик между процесорите в системата: Receive Packet Steering (RPS) и Receive Flow Steering (RFS).

RPS разпределя натоварването от получените пакети върху процесорите в системата. Това решение позволява обработката на пакети (например на IP и TCP) да се извършва успоредно. За всяко мрежово устройство ( или на всяка входяща опашка, в устройство с множество входящи потоци ), се хешира хедъра на пакета и се използва за индекс в маска с наличните процесори ( това може да се конфигурира ръчно в /sys/class/net//queues/rx-<n>/rps_cpus). Също така в RFS се използват и някои евристични алгоритми. Вместо произволно да се избира CPU от хеша, RFS се опитва да използва процесора, на който дадено приложение използва или е използвало системното извикване recvmsg (), с цел да се подобри използването на кеш паметта. Използва се и хардуерно хеширане, ако има такова.

2. Подобрения във файловата система Btrfs
   Поддръжка на директен вход/изход: това е техника, изпозлвана за да се заобиколи кеша на файловата система. Директният вход/ изход могат да навредят на производителността, но силно се използват във високо производителен софтуер като бази данни, които искат да имплементират свой собствен кеширащ алгоритъм.

3. Отложено записване на журнала в XFS
   Тази версия добавя нов режим на записване в журнала в XFS, наречен отложено записване. Това позволява да се натрупат множество асинхронни операции в паметта, вместо да се записват поотделно. Входно/изходният трафик генериран от журнала намалява в пъти. Производителността при работа с метаданните при големи натоварвания се увеличава значително. Форматът на журнала върху диска не е променен, само някои структури от данни в паметта и кода. Тази функция е експериментална, така че не се препоръчва за крайните потребители или производствени сървъри. Тези, които искат да го тестват, могат да го включат с mount опцията "-о delaylog".

4. Потребителски интерфейс за KDB
   Linux ядрото има дебъгeр още от 2.6.26, наричан Kgdb. Освен Kgdb съществува и KDB, разработен преди години от SGI. Ключовата разлика между Kgdb и KDB е, че при използването на Kgdb се изисква допълнителен компютър, за да се изпълни gdb клиента. Също така, можете да дебъгвате на ниво изходен код. От друга страна, KDB може да бъде изпълнен на локална машина за диагностика на системата, но не може да се използва за дебъгване на ниво изходен код. В тази версия Jason Weßel, от Windriver е променил KDB, така че да работи на основата на ядрото на gdb. По този начин могат да се използват и двата интерфейса.

5. Уплътняване на паметта
   Механизмът за уплътняване на паметта се опитва да намали фрагментацията на паметта в дадена зона като премества заетите страници памет, така че да се получи голям непрекъснат блок от тях. Когато уплътняването свърши, в паметта ще има един голям блок от заети страници и един от неизползвани. Това прави по-лесно заделянето на големи парчета памет. Механизмът е наречен "уплътняване", за да се различи от други видове дефрагментация.

Уплътняването включва два скенера, които работят в дадената зона от паметта, миграционен скенер и скенер за свободна памет. Миграционният скенер започва от началото на зоната и намира всички заети страници, които могат да бъдат преместени. Скенерът за свободна памет започва от края на зоната и търси достатъчно свободни страници, така че да премести в тях, всички намерени от предния скенер. Уплътняването свършва, когато двата скенера се срещнат и заетите страници са преместени. Тестове се показали, че количетвото на IO операции, нужни за да се задоволи голямо заделяне на страници намалява значително.

6. Поддръжка на множество мултикаст маршрутизиращи таблици
   Обикновенно мултикаст маршрутизатора стартира демон в потребителското пространство и решава какво да направи с милтикаст пакет, основавайки се на неговият изходен и краен адрес. В тази версия е добавена поддръжка за множество независими милтикаст рутиращи инстанции. Така ядрото е в състояние да вземе под внимание интерфейсите и маркерите на пакетите и да пусне едновременно множество инстанции на демона в потребителското пространство, като всеки от тях да използва отделна таблица за рутиране.

7. Поддръжка на L2TP версия 3 (RFC 3931)
   Тази версия добавя поддръжка на Layer 2 Tunneling Protocol (L2TP), RFC 3931. L2TP предлага динамичен механизъм за тунелиране на Layer 2 (L2) "схеми" през пакетно ориентирана мрежа от данни (например през IP).L2TP, първоначално дефиниран в RFC 2661, е стандартен метод за тунелиране на Point-to-Point Protocol (PPP) [RFC1661] сесии. Той е пригоден за тунелиране на редица от L2 протоколи, включително ATM, Frame Relay, HDLC, и дори RAW ethernet пакети.

Пълен списък с промените, както и повече информация, можете да намерите на адрес kernelnewbies.org