Resend -- filter acting up again. -------- Original Message -------- * Attachments * Mails from other lists * HTML mails (also multipart text/html!) If you think your mail does not violate these rules and was declined anyway, contact the owner at: opensuse-kernel+owner@opensuse.org --- below this line the first 100 lines of the denied message ---> To: Larry Finger CC: Jean Delvare , Cristian Rodríguez , Jeff Mahoney , opensuse-kernel list , Jean-Baptiste Giraudeau References: <5384B3F4.3050308@opensuse.org> <1401898027.4330.127.camel@chaos.site> <538F46A1.9070104@lwfinger.net> Larry Finger wrote:

On 06/04/2014 11:07 AM, Jean Delvare wrote:

...

So unless someone can provide a good reason why we should stick to SLAB, I vote for switching to SLUB.

+1

I build my own kernels, and I have used SLUB without problems for several years with openSUSE. As I run new kernel versions, I have hit some SLUB bugs in the -git or -rc1, but those are always fixed long before the stable release.

+1 Ditto on the above. I found the below on stack overflow -- which recommends slub as SLUB is the updated design for SLAB as optimized for multiprocessor systems. By using SLAB, we are NOT using the default. Linux currently offers three choices for its "slab" allocator: Slab is the original, based on Bonwick's seminal paper and available since Linux kernel version 2.2. It is a faithful implementation of Bonwick's proposal, augmented by the multiprocessor changes described in Bonwick's follow-up paper[2]. Slub is the next-generation replacement memory allocator, which has been the default in the Linux kernel since 2.6.23. It continues to employ the basic "slab" model, but fixes several deficiencies in Slab's design, particularly around systems with large numbers of processors. Slub is simpler than Slab. SLOB (Simple List Of Blocks) is a memory allocator optimized for embedded systems with very little memory—on the order of megabytes. It applies a very simple first-fit algorithm on a list of blocks, not unlike the old K&R-style heap allocator. In eliminating nearly all of the overhad from the memory allocator, SLOB is a good fit for systems under extreme memory constraints, but it offers none of the benefits described in 1 and can suffer from pathological fragmentation. 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. -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org