On 10 December 2013 09:30, David Rientjes <rient...@google.com> wrote: > Any reason that BFS hardcodes CONFIG_SLUB as the only slab allocator > allowed? I've cc'd Pekka and Christoph and I'm sure they'd be interested > in any reasons that CONFIG_SLAB doesn't work correctly with a different > drop-in scheduler, or is it just that interactivity has tested better with > slub?
Hi David. Thanks, and an interesting question you have there. To be honest it's been probably over 2 years since I hard coded SLUB into the BFS patch and all I can recall is that it caused a crash that was purely due to enabling SLAB that went away with SLUB when used with BFS. Despite the possibility that BFS exposes an issue in the kernel that may be possible with the mainline scheduler (due to BFS being extremely good at exposing race conditions), if the problem is never reported with mainline, it's probably of no significance to mainline. Changes in scheduler initialisation sequence alone may be the real reason. The same goes with the offline CPU code which had to be drastically reworked to work properly with suspend/hibernate on BFS. There certainly have been cases that BFS has exposed races that have only become apparent in mainline a long time later. Here's one I recall reporting as a potential issue a long time ago here: http://marc.info/?l=linux-kernel&m=130613435113919&w=2 It was instantly discounted as not a problem, yet about 6 months later a real issue in this code showed up. I have no idea if the CONFIG_SLAB problem falls into this category. Regards, Con -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/