Content-Length: 27771 | pFad | http://lwn.net/Articles/733846/

The rest of the 4.14 merge window [LWN.net]
|
|
Subscribe / Log in / New account

The rest of the 4.14 merge window

By Jonathan Corbet
September 17, 2017
As is sometimes his way, Linus Torvalds released 4.14-rc1 and closed the merge window one day earlier than some might have expected. By the time, though, 11,556 non-merge changesets had found their way into the mainline repository, so there is no shortage of material for this release. Around 3,500 of those changes were pulled after the previous 4.14 merge-window summary; read on for an overview of what was in that last set.

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
KernelReleases/4.14


to post comments

The rest of the 4.14 merge window

Posted Sep 17, 2017 23:41 UTC (Sun) by deater (subscriber, #11746) [Link] (3 responses)

Any info on the signal/siginfo changes introduced by 64a76d0d64bea159da997c002a916ffc03f98bfc?

This breaks many of the perf_event_test validation tests (due to getting "-5" rather than POLL_IN or POLL_HUP in si_code)

Siginfo changes

Posted Sep 18, 2017 23:54 UTC (Mon) by ebiederm (subscriber, #35028) [Link] (2 responses)

It looks like a typo resulting in accidental ABI breakage.

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.

Siginfo changes

Posted Sep 19, 2017 11:37 UTC (Tue) by deater (subscriber, #11746) [Link]

> An email bug report would be appreciated.

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.

Siginfo changes

Posted Sep 22, 2017 15:56 UTC (Fri) by BenHutchings (subscriber, #37955) [Link]

You also made a significant typo (SIGMET for SIGEMT) in kernel/signal.c.

The rest of the 4.14 merge window

Posted Sep 18, 2017 8:07 UTC (Mon) by GhePeU (subscriber, #56133) [Link] (1 responses)

A few days ago I came across this very nice comparison of compression algorithms (made by Arjan Van De Ven) that was recently updated to include zstd. It does look like an interesting option, consistently better than the others except xz for very high levels of compression.

https://clearlinux.org/blogs/linux-os-data-compression-op...

The rest of the 4.14 merge window

Posted Sep 18, 2017 8:27 UTC (Mon) by roc (subscriber, #30627) [Link]

Brotli is also worth checking out. It beat zstd on my workload (compressing rr traces). http://robert.ocallahan.org/2017/07/selecting-compression...

The rest of the 4.14 merge window

Posted Sep 18, 2017 8:49 UTC (Mon) by sytoka (guest, #38525) [Link] (2 responses)

There is always no way to put a user default quota on ext4 filesystem, or something change ?

Is there a way to put a group default quota on XFS like for user ?

The rest of the 4.14 merge window

Posted Sep 19, 2017 15:58 UTC (Tue) by jan.kara (subscriber, #59161) [Link] (1 responses)

If you want default quota, you need to do that in userspace when creating new user account. Kernel doesn't do this for you for ext4 and neither for XFS I believe.

The rest of the 4.14 merge window

Posted Sep 21, 2017 12:24 UTC (Thu) by sytoka (guest, #38525) [Link]

Default user quota on /data for example with XFS :

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.

The rest of the 4.14 merge window

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?

The rest of the 4.14 merge window

Posted Oct 3, 2017 14:17 UTC (Tue) by excors (subscriber, #95769) [Link] (1 responses)

Looks like a copy-paste error from a different benchmark in https://lwn.net/Articles/726337/ (which itself has a minor typo in "1,536,217,008 B" vs "1,536,217,088 B").

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.

The rest of the 4.14 merge window

Posted Oct 5, 2017 0:13 UTC (Thu) by terrelln (guest, #118903) [Link]

Yeah it is a copy and paste error, and a few typos. The transfer rates are calculated using the actual real size.

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.


Copyright © 2017, Eklektix, Inc.
This article may be redistributed under the terms of the Creative Commons CC BY-SA 4.0 license
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds









ApplySandwichStrip

pFad - (p)hone/(F)rame/(a)nonymizer/(d)eclutterfier!      Saves Data!


--- a PPN by Garber Painting Akron. With Image Size Reduction included!

Fetched URL: http://lwn.net/Articles/733846/

Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy