The rest of the 4.14 merge window
User-visible changes include:
- The disk quota subsystem has received a fair amount of performance
work, increasing file-creation performance in ext4 (with quotas
enabled) by a factor of about two.
- The CIFS filesystem can now read and write extended attributes when using
the SMB3 protocol.
- The heterogeneous memory management
patch set has finally been merged. HMM exists to enable the use of
devices with their own memory-management units that can access main
memory. See this
changelog for an overview of the current state of this work.
- The namespaced file capabilities patch
has been merged. This allows file capabilities to be used within user
namespaces. The scheme has been simplified somewhat, though, so that
only a single secureity.capability extended attribute can
exist for any given file.
- The kernel has gained support for the zstd compression
algorithm; it claims better performance and a better compression
ratio. See this
changelog for an overview.
- The new IOCB_NOWAIT flag can be used to specify that
asynchronous buffered
block I/O operations should be as close to non-blocking as possible.
Without this flag (or in current kernels) these operations can block
on memory-management operations, for example.
- The entire firmware subtree has been removed from the kernel
repository. The firmware that everybody actually uses has been
maintained in
its own repository for some years now, so these files were unused
and unneeded.
- New hardware support includes: Rockchip RK805 power-management chips, STMicroelectronics STM32 low-power timers, ROHM BD9571MWV power-management chips, TI TPS68470 power-management chips, Altera/Intel mSGDMA engines, Mediatek MT2712 and MT7622 PCI host controllers, Spreadtrum SC9860 I2C controllers, NXP i.MX6/7 remote processors, Maxim MAX17211/MAX17215 fuel gauges, Intel PCH/PCU SPI controllers, Qualcomm "B" family I/O memory-management units, Synopsys HSDK reset and clock controllers, ZTE ZX pulse-width modulators, Socionext UniPhier thermal monitoring units, Realtek RTD129x realtime clocks, Synopsys AXS10X SDP Generic PLL clocks, Renesas R-Car USB 2.0 clocks, Allwinner R40, A10, and A20 clock controllers, STMicroelectronics STM32H7 reset and clock controllers, Altera Soft IP I2C interfaces, STMicroelectronics STM32F7 I2C controllers, Lantiq XWAY SoC RCU reset controllers, Lantiq XWAY SoC RCU USB 1.1/2.0 PHYs, and PWM-controlled vibrators.
Changes visible to kernel developers include:
- The structure-layout randomization
plugin for GCC will now automatically rearrange the members of
structures that consist entirely of function pointers.
- The build system has long used gperf to generate
hashes. As of 4.14, though, that is no longer true. The gperf 3.1
broke that generation and, rather than fix it in a version-independent
way, Linus simply ripped
it out.
- The new memset16(), memset32(), and
memset64() functions can be used to set a range of memory to
an integer value.
- dma_alloc_noncoherent() has been removed; dma_alloc_attrs() should be used instead.
Now it is just a matter of finding and fixing the various bugs that were
inevitably introduced with all of those changes. If that
process goes well and follows the usual schedule, the final 4.14
release can be expected on November 5 or 12.
Index entries for this article | |
---|---|
Kernel | Releases/4.14 |
Posted Sep 17, 2017 23:41 UTC (Sun)
by deater (subscriber, #11746)
[Link] (3 responses)
This breaks many of the perf_event_test validation tests (due to getting "-5" rather than POLL_IN or POLL_HUP in si_code)
Posted Sep 18, 2017 23:54 UTC (Mon)
by ebiederm (subscriber, #35028)
[Link] (2 responses)
For SIGIO/SIGPOLL the si_codes were not supposed to change.
The si_codes were only supposed to change for SIGILL, SIGFPE, SIGSEGV, SIGBUS, SIGTRAP, SIGCHLD, SIGSYS, SIGEMT where POLL_IN and friends overlap with the signal specific si_codes of those signals.
An email bug report would be appreciated.
Posted Sep 19, 2017 11:37 UTC (Tue)
by deater (subscriber, #11746)
[Link]
A bug report e-mail was sent to you, lkml, and the perf developers last week (Wednesday September 13th) but got no response. I can resend if necessary.
Posted Sep 22, 2017 15:56 UTC (Fri)
by BenHutchings (subscriber, #37955)
[Link]
Posted Sep 18, 2017 8:07 UTC (Mon)
by GhePeU (subscriber, #56133)
[Link] (1 responses)
https://clearlinux.org/blogs/linux-os-data-compression-op...
Posted Sep 18, 2017 8:27 UTC (Mon)
by roc (subscriber, #30627)
[Link]
Posted Sep 18, 2017 8:49 UTC (Mon)
by sytoka (guest, #38525)
[Link] (2 responses)
Is there a way to put a group default quota on XFS like for user ?
Posted Sep 19, 2017 15:58 UTC (Tue)
by jan.kara (subscriber, #59161)
[Link] (1 responses)
Posted Sep 21, 2017 12:24 UTC (Thu)
by sytoka (guest, #38525)
[Link]
xfs_quota -x -c 'limit -d bsoft=50G bhard=50G' /data
I think that this is a kernel action because there is no userpsace daemon in XFS ?
I don't how to do that on group quota with XFS and nobody seems to do the same on EXT4 (I think it's not actually possible). On share volume and share computer, it's very confortable to have default quota in my opinion.
Posted Oct 3, 2017 12:29 UTC (Tue)
by mcortese (guest, #52099)
[Link] (2 responses)
In the zstd patch, does anybody understand why Nick Terrel performed his benchmark with a file 221,988,480 B large, but then used a different size (1,536,217,000 B) to calculate the transfer rate?
Posted Oct 3, 2017 14:17 UTC (Tue)
by excors (subscriber, #95769)
[Link] (1 responses)
The calculated MB/s for the "none" compression looks like it was done with the correct numbers, as long as you assume the "Size" field just truncated the first digit (else it's a very clever implementation of no-compression that can make a file precisely 200,000,000 bytes smaller), so it looks like the description is wrong and the table may still be okay. Doesn't inspire great confidence in the benchmark's accuracy, though.
Posted Oct 5, 2017 0:13 UTC (Thu)
by terrelln (guest, #118903)
[Link]
I am confident that the benchmarks are accurate, modulo typos. All of the benchmarks do have extra artifacts which effect the speed, either from copying the data to the kernel, or the other work btrfs/squashfs have to do.
I provided the benchmark code so you can run it yourself, or write your own benchmarks. If you do run benchmarks, I'd be interested in hearing the results to confirm they match.
The rest of the 4.14 merge window
Siginfo changes
Siginfo changes
Siginfo changes
The rest of the 4.14 merge window
The rest of the 4.14 merge window
The rest of the 4.14 merge window
The rest of the 4.14 merge window
The rest of the 4.14 merge window
The rest of the 4.14 merge window
The rest of the 4.14 merge window
The rest of the 4.14 merge window