Boost::pool works very well when you're allocated "same" sized objects. That's not our situation, we're allocating lots of different sized objects -- some small, some large. The only way that Boost::pool supports that situation is to use the "ordered_free" operation to keep the freelist sorted (if you don't use it then you'll get fragmentation that'll prevent allocation of large objects -- even though there's plenty of free memory). The implementation of the sorted freelist is O(N). Which should work well for small pools, but that's the exact opposite of the desired use for Ceph, we're targeting large pools (think 1GB). I didn't word it very well, but my proposal doesn't actually change the underlying malloc/free algorithm, rather it's intended to put some statistics around memory usage so that we can self-trim our memory pools. Allen Samuels SanDisk |a Western Digital brand 2880 Junction Avenue, San Jose, CA 95134 T: +1 408 801 7030| M: +1 408 780 6416 allen.samuels@xxxxxxxxxxx > -----Original Message----- > From: Jesse Williamson [mailto:jwilliamson@xxxxxxx] > Sent: Wednesday, September 28, 2016 11:17 PM > To: Sage Weil <sage@xxxxxxxxxxxx> > Cc: Allen Samuels <Allen.Samuels@xxxxxxxxxxx>; Ceph Development > <ceph-devel@xxxxxxxxxxxxxxx> > Subject: Re: Memory Pooling and Containers > > On Wed, 28 Sep 2016, Sage Weil wrote: > > > It would be nice to build this on top of existing allocator libraries > > if we can. For example, something in boost. I took a quick peek the > > other day and didn't find something that allowed simple interrogation > > about utilization, though, which was surprising. > > Boost::pool look to me like it should fufill most of the requirements, but I > haven't used it in production: > http://www.boost.org/doc/libs/1_62_0/libs/pool/doc/html/index.html > > By "iterrogation about utilization", do you mean statistics about the allocator > activity? > > -Jesse -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
