Hi Jonas > > It would be possible to check if a whole chunk is > > now in the freelist and all the allocated pages could > > be freed now, but this would require some algorithms > > I doubt will be implemented since > > the allocator is going to be replaced anyway... > > Would it be worthwhile having a kernel thread or some > other not so very periodic routine to try (for as long as we > want the PARANOID_KFREE) to remove empty bins? If we didn't intend to throw away the allocator it would certainly be the way to go. > I don't think the routine to find empty bins would have to be > complex, and I'm guessing its thread, or whatever, could be > scheduled with a frequency of seconds or less. Sure, but that would give some quite "strange" times where closing apps sometimes results in a slowdown for a second or so and sometimes it doesn't. Not a huge problem, just a possible irritation. > As an alternative to directly removing bins, one could have > them age and convert them to larger element bins over time, > with fewer elements and thus shorter freelists, and eventually > remove the expired, empty 2048 byte size bins, given a 4kb > page size. Would that make sense? Well that gets kinda complex now ;-). Again, it could certainly be implemented, but since a) the allocator will be replaced and b) having long freelists around doesn't really hurt when we eventually turn off PARANOID_KFREE, I just don't see it as a particularly usful thing to spend time on. I am going to take a look at simply sorting the freelists which should have no real performance impact and speed up the lookup considerably. That will probably be a good enough fix for the current situation. Regards Michael