Hello Linda, it seems you haven't quite understood what was written. On Fri, 28 Aug 2015 12:01:11 -0700 "Linda A. Walsh" <suse@tlinx.org> wrote:
[...] From stackoverflow:
First, what makes stackoverflow a better source of information than an in-house benchmark?
[...] What should you use? Slub, unless you are building a kernel for an embedded device with limited in memory. In that case, I would benchmark Slub versus SLOB and see what works best for your workload. There is no reason to use Slab; it will likely be removed from future Linux kernel releases.
==============
I.e. if suse's aiming at small embedded devices/or optimizing it for toasters and microwave ovens, SLAB is recommended.
Wrong. Read the above quotation again. If you aim at small embedded devices, you should use SLOB, not SLAB. This was even mentioned in this thread before.
But if suse wants to support computers with *more processors* (seems to be the trend for most customers), then SLUB is recommended.
The wonders of using passive voice. WHO made the recommendation? What did they use apart from argumentum ad novitatem? (See https://en.wikipedia.org/wiki/Appeal_to_novelty)
So to turn the inertial question around, why GOOD reasons does Suse have for staying with a memory allocator designed for single procesor-embeded devices vs. larger multi-core systems?
We, our partners and our customers have tested this memory allocator on systems with thousands of CPUs and a variety of different workloads. No bugs were found, and the performance was not an issue. Why should SUSE suddenly throw away results of all that testing?
Of course, it's too bad such conservative thinking didn't go into areas regarding system boot and service management.... *ahem*....
While I would probably agree here, it's not really relevant to the discussion at hand. Even if I eventually agree that switching to systemd/dracut (whatever you had in mind) was a mistake, does it mean that SUSE must from now on repeat the same mistake in other areas (choosing the kernel allocator)? Cheers, Petr Tesarik -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org