1. Поддръжка на архитектурата Tilera
Процесорът Tile е ново CPU, произвеждано от Tilera Corporation. Той е с многоядрен дизайн, предназначен да поддържа до стотици ядра на един чип. Целта е да се осигури висока производителност на процесора, с добра енергийна ефективност, и с по-голяма гъвкавост, отколкото процесорите със специално предназначение като DSP-тата. Чипът се състои от мрежа от 64 "плочки", в която всяка плочка има процесор с общо предназначение, кеш и неблокируем рутер, който плочката използва за комуникация с другите плочки.

2. Fanotify - нов интерфейс за известия от файловата система
Fanotify е поредният интерфейс за известия от файловата система, предназначен да замести inotify и dnotify ( и двете са пренаписани на базата на fanotify ). Той предоставя, както базиран на събитие ( отваряне, затваряне, четене, писане ) файлов дескриптор, така и такъв само за четене. Това трябва да реши редица проблеми със състезания за ресурси и мащабируемостта на inotify и dnotify и да позволи да се блокира или контролира дадено известяване.

3. KMS+KDB интеграция
В тази версия е добавена възможност да активирате дебъгера на ядрото KDB, докато изпозлвате X.org сесия. При натискане на Sysrq-g, ще се отвори KDB конзола, а при излизането от нея( с командата "go" ), ще се върнете на вашия десктоп.
KMS + KDB интеграцията е имплементирана само за чипове на Интел, в бъдеще ще бъде добавена и за останалите чипове. Инструкции как да компилирате ядро с включена интеграция на KMS + KDB, можете да намерите тук.

4. Конкурентно управляеми работни опашки
Работните опашки са "пуул за нишки", които се използват на много места в ядрото. Този механизъм позволява да се поставят в опашки извиквания на функции от ядрото и да бъдат изпълнявани в бъдеще. Тези опашки могат да бъдат изпълнявани от една обща нишка в ядрото ( за това са "event/n" процесите ), но също така е възможно и да се създаде отделна нишка за даден драйвър от подсистемата за работни опашки ( такива са и много от останалите нишки в ядрото ). Проблемът с тази реализация е, че общият брой на нишки в ядрото, използвани да стартират работни опашки и опашките, стартирани на тях, не се контролира по никакъв начин. Ако има повече работни опашки, от колкото процесори, тогава ще възникне състезание за ресурси между нишките в ядрото.
В тази версия работните опашки са преработени като им е добавен мениджър. Вече няма отделни нишки( с изключение на кода, който не е преобразуван към новото API), вместо това има пуул от нишки, който нараства динамично с цел да поддържа системата заета, разчитайки на броя акумулирани опашки. Също така новият дизайн може да замени бавно работещ код( друг пуул се използва за да се стартират определен вид операции, които обикновенните опашки не могат да изпълнят правилно)

5. AppArmor
AppArmor е модул за сигурност. Той предоставя контрол на достъпа, базиран на пътя. Първоначално AppArmor бе разработен от Имуникс(Immunix) през 1998, а после от Новел. След това проектът бе поет от Каноникъл и интегриран в Убунту. От тази версия AppArmor вече е част от ядрото. Още информация за AppArmor.