missing: move sched.h related definitions to missing_sched.h

[thirdparty/systemd.git] / NEWS

diff --git a/NEWS b/NEWS
index bbd1e2d8a1d63b01bd9a42835f97f957f13bb798..5a6ebf0b4fa02d78d195fc8a0afcbedfa24eda33 100644 (file)
--- a/NEWS
+++ b/NEWS
@@ -31,7 +31,7 @@ CHANGES WITH 240 in spe:
           userspace processes is set to 1024 (soft) and 4096
           (hard). Previously, systemd passed this on unmodified to all
           processes it forked off. With this systemd release the hard limit
-          systemd passes on is increased to 256K, overriding the kernel's
+          systemd passes on is increased to 512K, overriding the kernel's
           defaults and substantially increasing the number of simultaneous file
           descriptors unprivileged userspace processes can allocate. Note that
           the soft limit remains at 1024 for compatibility reasons: the
@@ -50,7 +50,19 @@ CHANGES WITH 240 in spe:
           hard limit during initialization. Of course, when doing that they
           must do this acknowledging the fact that they cannot use select()
           anymore (and neither can any shared library they use — or any shared
-          library used by any shared library they use and so on).
+          library used by any shared library they use and so on). Which default
+          hard limit is most appropriate is of course hard to decide. However,
+          given reports that ~300K file descriptors are used in real-life
+          applications we believe 512K is sufficiently high as new default for
+          now. Note that there are also reports that using very high hard
+          limits (e.g. 1G) is problematic: some software allocates large arrays
+          with one element for each potential file descriptor (Java, …) — a
+          high hard limit thus triggers excessively large memory allocations in
+          these applications. Hopefully, the new default of 512K is a good
+          middle ground: higher than what real-life applications currently
+          need, and low enough for not triggering excessively large allocations
+          in problematic software. (And yes, somebody should fix Java, to not
+          require such excessive allocations.)
 
         * The fs.nr_open and fs.file-max sysctls are now automatically bumped
           to the highest possible values, as separate accounting of file