Messages in this thread | | | Date | Tue, 5 Oct 2021 13:31:02 +0000 | From | Hyeonggon Yoo <> | Subject | Re: [QUESTION] is SLAB considered legacy and deprecated? |
| |
On Mon, Oct 04, 2021 at 01:39:46PM +0200, Vlastimil Babka wrote: > On 10/4/21 08:01, Hyeonggon Yoo wrote: > > On Sun, Oct 03, 2021 at 06:25:29PM -0700, David Rientjes wrote: > >> I would disagree that SLAB isn't currently maintained, I think it's > >> actively maintained. > > > > I thought it was not actively maintained because most of patches were > > fixups and cleanups for years and as Vlastimil said, new features are > > Fixups and cleanups still count as "actively maintained". The opposite > case would be "nobody uses it because it was broken for years since > commit X and we only noticed now". >
Yup, there seems I was differently using meaning of "actively maintained".
> > only added to SLUB. development was focused on SLUB. > > > >> I think the general guidance is that changes for both allocators can still > >> be merged upstream if they show a significant win (improved performnace, > >> maintaining performance while reducing memory footprint, code hygiene, > >> etc) and there's no specific policy that we cannot make changes to > >> mm/slab.c. > > > > Good. > > > > I see things to improve in SLAB and want to improve it. > > I will appreciate if you review them. > > It would be great if your motivation started with "I prefer SLAB over > SLUB because X and Y but I need to improve Z", not just a theoretical > concern. >
Thank you for advice. by making dumb patches I realized that , yeah, just a theoretical concern does not help.
I should have more understanding on internals of slab allocators and on how their characteristics affect performance depending on situation. and most importantly I should have actual evidence of performance measurement.
I'm sorry and Thank you for thinking about and answering my (somewhat dumb) questions. But I'm happy that I'm learning a lot from your feedback.
> > Thanks, > > Hyeonggon > > >
| |