All of lore.kernel.org
 help / color / mirror / Atom feed
From: Allen Samuels <Allen.Samuels@sandisk.com>
To: Jesse Williamson <jwilliamson@suse.de>, Sage Weil <sage@newdream.net>
Cc: Ceph Development <ceph-devel@vger.kernel.org>
Subject: RE: Memory Pooling and Containers
Date: Wed, 28 Sep 2016 21:31:40 +0000	[thread overview]
Message-ID: <BLUPR0201MB152427C4BD08DEDB9178C89AE8CF0@BLUPR0201MB1524.namprd02.prod.outlook.com> (raw)
In-Reply-To: <alpine.LSU.2.20.1609281413450.13361@ancalagon.suse.de>

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@SanDisk.com

> -----Original Message-----
> From: Jesse Williamson [mailto:jwilliamson@suse.de]
> Sent: Wednesday, September 28, 2016 11:17 PM
> To: Sage Weil <sage@newdream.net>
> Cc: Allen Samuels <Allen.Samuels@sandisk.com>; Ceph Development
> <ceph-devel@vger.kernel.org>
> 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

  reply	other threads:[~2016-09-28 21:31 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-27 20:30 Memory Pooling and Containers Allen Samuels
2016-09-27 23:00 ` Gregory Farnum
2016-09-28  9:13   ` Allen Samuels
2016-09-28 13:16   ` Sage Weil
2016-09-28 13:27 ` Sage Weil
2016-09-28 13:34   ` Haomai Wang
2016-09-28 15:56     ` Allen Samuels
2016-09-28 19:39     ` Allen Samuels
2016-09-28 15:56   ` Allen Samuels
2016-09-28 21:16   ` Jesse Williamson
2016-09-28 21:31     ` Allen Samuels [this message]
2016-09-30 14:22       ` Sage Weil
2016-09-30 14:30         ` Allen Samuels
2016-09-30 21:47           ` Jesse Williamson
2016-09-30 18:54         ` Gregory Farnum

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=BLUPR0201MB152427C4BD08DEDB9178C89AE8CF0@BLUPR0201MB1524.namprd02.prod.outlook.com \
    --to=allen.samuels@sandisk.com \
    --cc=ceph-devel@vger.kernel.org \
    --cc=jwilliamson@suse.de \
    --cc=sage@newdream.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.