On 08/18/2016 04:52 AM, Michal Hocko wrote:
I am not opposing the patch (to be honest it is quite neat) but this
is buggering me for quite some time. Sorry for hijacking this email
thread but I couldn't resist. Why are we trying to optimize SLAB and
slowly converge it to SLUB feature-wise. I always thought that SLAB
should remain stable and time challenged solution which works reasonably
well for many/most workloads, while SLUB is an optimized implementation
which experiment with slightly different concepts that might boost the
performance considerably but might also surprise from time to time. If
this is not the case then why do we have both of them in the kernel. It
is a lot of code and some features need tweaking both while only one
gets testing coverage. So this is mainly a question for maintainers. Why
do we maintain both and what is the purpose of them.
Michal,
Speaking about this patch specifically - I'm not trying to optimize SLAB
or make it more similar to SLUB. This patch is a bug fix for an issue
where the slowness of 'cat /proc/slabinfo' caused timeouts in other
drivers. While optimizing that flow, it became apparent (as Christoph
pointed out) that one could converge this patch to SLUB's current
implementation. Though I have not done that in this patch (because that
warrants a separate patch), I think it makes sense to converge where
appropriate, since they both do share some common data structures and
code already.
Thanks,
Aruna
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>