KernelNewbies:

Linux 3.15 [https://lkml.org/lkml/2014/6/8/70 has been released] on Sun, 8 Jun

/!\ /!\ This page is not complete /!\ /!\

While the page is completed, you can read about Linux 3.15 in the following sites:

1. Prominent features

1.1. Faster resume from power suspend in systems with hard disks

Resuming a system from suspend used to take a long time in systems with traditional hard disks, because the system blocks the resume process until the hard disk finish powering up. In this release, commands are sent to the hard disk asynchronously, so the entire resuming process isn't paused by the hard disk. The end result is that systems with hard disks will resume several seconds faster with this Linux release.

For more details, see this [https://01.org/suspendresume/blogs/tebrandt/2013/hard-disk-resume-optimization-simpler-approach blog entry]

Code: [http://git.kernel.org/linus/;a=commit;h=200421a80f6e0a9e39d698944cc35cba103eb6ce commit 1], [http://git.kernel.org/linus/;a=commit;h=3c31b52f96f7b559d950b16113c0f68c72a1985e 2]

1.2. Improved working set size detection

When there is not enough room for all memory in RAM, the Linux kernel is in charge of deciding which memory must be kept in RAM, and which must be sent to swap or discarded. In order to make good decisions, it is necessary to track which memory is most used and deserves to be kept in RAM, and which memory is not used often and can be evicted. The way the Linux kernel does this is by keeping an "inactive" and "active" list, when some data needs to be moved to RAM its memory is marked as active. As more and more memory gets used, the active list gets filled and the less used memory is moved to the inactive list.

The problem with this algorithm is to know how big must be each list. Linux used to have a policy of not allowing the active list to grow larger than the inactive, but this approach caused problems. In this release, Linux does more advanced tracking of how memory gets used and can balance better the size of the lists, which makes Linux perform better in certain workloads, adapt better to workload size changes, and creates a foundation to build improved policies in the future.

For more details, read this recommended link: [http://lwn.net/Articles/495543/ Better active/inactive list balancing]

[http://git.kernel.org/linus/e7b563bb2a6f4d974208da46200784b9c5b5a47e commit 1], [http://git.kernel.org/linus/449dd6984d0e47643c04c807f609dd56d48d5bcc 2], [http://git.kernel.org/linus/d26914d11751b23ca2e8747725f2cae10c2f2c1b 3], [http://git.kernel.org/linus/6dbaf22ce1f1dfba33313198eb5bd989ae76dd87 4], [http://git.kernel.org/linus/a528910e12ec7ee203095eb1711468a66b9b60b0 5]

1.3. EFI 64 bit kernels can be booted from 32 bit firmware

Most modern x86 CPUs are 64bit, but many modern systems ship with a 32 bit EFI implementation. This didn't allow to boot a Linux 64 bit EFI kernel from these 32 bit EFI systems. This limitation has been removed, a 64-bit kernel can be booted on 32-bit firmware that runs on 64 bit CPUs (note that it is not possible to boot a mixed-mode enabled kernel via the EFI boot stub - a bootloader that supports the EFI handover protocol must be used)

Code: [http://git.kernel.org/linus/0154416a71c2a84c3746c8dd8ed25287e36934d3 commit 1], [http://git.kernel.org/linus/4f9dbcfc40299ddaa780fe8c1cd74998c1be3af5 2], [http://git.kernel.org/linus/54b52d87268034859191d671505bb1cfce6bd74d 3], [http://git.kernel.org/linus/099240ac111aac454962e6399c0cc51d1511504a 4], [http://git.kernel.org/linus/b8ff87a6158886771677e6dc8139bac6e3cba717 5], [http://git.kernel.org/linus/e10848a26a962e404ac00c897dfe54f14290806d 6], [http://git.kernel.org/linus/18c46461d9e42d398536055f31f58cdcd2c6347e 7], [http://git.kernel.org/linus/9a11040ff962304c1838aa9a9f33be78784eae47 8], [http://git.kernel.org/linus/3f4a7836e33134d4ac34fa7c99788f0c6a79fa1c 9], [http://git.kernel.org/linus/c116e8d60adabfd545a269fccab85e77febc1643 10], [http://git.kernel.org/linus/7d453eee36ae4cf30fc2f2faae54f634c4f863b7 11]

1.4. New file locking scheme: file private locks

Due to some unfortunate history, POSIX locks have very strange and unhelpful semantics: they are dropped whenever the process closes any file descriptor associated with the inode, and locks taken between threads within the same process won't conflict with one another, which renders them useless for synchronization between threads.

This release adds a new type of lock that attempts to address these issues. These locks will conflict with classic POSIX read/write locks, but have semantics that are more like BSD locks with respect to inheritance and behavior on close.

For more documentation and details about the new locking API, read this recommended LWN link: [http://lwn.net/Articles/586904/ File-private POSIX locks]

Code: [http://git.kernel.org/linus/5d50ffd7c31dab47c6b828841ca1ec70a1b40169 commit]

KernelNewbies: Linux_3.15 (last edited 2014-06-09 20:28:27 by diegocalleja)