Re: inline vector container

Re: inline vector container

[Sage Weil]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1278 bytes --]

On Wed, 3 Feb 2016, Allen Samuels wrote:
> One thing that the code base needs is a simple vector container that is
> optimized for a small number of elements, i.e., for small element counts we
> avoid the malloc/free overhead. But fully supports being resized into larger
> containers that are unbounded. Of course it will need to follow all of the
> proper object copy/move semantics so that things like unique_ptr, etc work
> correctly.
> 
> I heard rumors that there was one available in the boost world, but I can’t
> seem to find it. Do you know about one being available?

http://www.boost.org/doc/libs/1_60_0/doc/html/boost/container/small_vector.html

> I’ve been prototyping one myself, just to get re-familiar with all of the
> C++11 move sementics, and trivial constructors, etc.
> 
> The code is pretty complete, but the testing gets rather involved. There’s
> no reason to contain this if it’s available elsewhere. But if it isn’t I
> plan on continuing this…

I think Casey had prototyped something similar using a custom allocator, 
too, but I didn't actually look at the result.  And Matt talked about just 
pulling the boost one in-tree until we get updated boost in the supported 
distros, but I forget if he ran into problems there or not...

sage

Re: inline vector container

[Matt Benjamin]

Hi,

I think we should go with small_vector for this role, yes.  I found two issues.  First, there are critical defects in small_vector prior to boost 1.6.0.  Second, though it is header-only, the coupling with related version-specific boost types (container, allocator, respective detail types, and platform-specific selectors...) seems to make pulling it in separately pretty unrealistic as an option.  I looked at the cost of pulling in and selectively compiling (libs) an entire boost 1.6, and that went a lot easier (added less than a minute to my build time).

Matt

----- Original Message -----
> From: "Sage Weil" <sweil@redhat.com>
> To: "Allen Samuels" <Allen.Samuels@sandisk.com>
> Cc: ceph-devel@vger.kernel.org, mbenjami@redhat.com, cbodley@redhat.com
> Sent: Wednesday, February 3, 2016 3:04:57 PM
> Subject: Re: inline vector container
> 
> On Wed, 3 Feb 2016, Allen Samuels wrote:
> > One thing that the code base needs is a simple vector container that is
> > optimized for a small number of elements, i.e., for small element counts we
> > avoid the malloc/free overhead. But fully supports being resized into
> > larger
> > containers that are unbounded. Of course it will need to follow all of the
> > proper object copy/move semantics so that things like unique_ptr, etc work
> > correctly.
> > 
> > I heard rumors that there was one available in the boost world, but I can’t
> > seem to find it. Do you know about one being available?
> 
> http://www.boost.org/doc/libs/1_60_0/doc/html/boost/container/small_vector.html
> 
> > I’ve been prototyping one myself, just to get re-familiar with all of the
> > C++11 move sementics, and trivial constructors, etc.
> > 
> > The code is pretty complete, but the testing gets rather involved. There’s
> > no reason to contain this if it’s available elsewhere. But if it isn’t I
> > plan on continuing this…
> 
> I think Casey had prototyped something similar using a custom allocator,
> too, but I didn't actually look at the result.  And Matt talked about just
> pulling the boost one in-tree until we get updated boost in the supported
> distros, but I forget if he ran into problems there or not...
> 
> sage

-- 
-- 
Matt Benjamin
Red Hat, Inc.
315 West Huron Street, Suite 140A
Ann Arbor, Michigan 48103

http://www.redhat.com/en/technologies/storage

tel.  734-707-0660
fax.  734-769-8938
cel.  734-216-5309
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: inline vector container

[Milosz Tanski]

On Wed, Feb 3, 2016 at 3:57 PM, Matt Benjamin <mbenjamin@redhat.com> wrote:
>
> Hi,
>
> I think we should go with small_vector for this role, yes.  I found two issues.  First, there are critical defects in small_vector prior to boost 1.6.0.  Second, though it is header-only, the coupling with related version-specific boost types (container, allocator, respective detail types, and platform-specific selectors...) seems to make pulling it in separately pretty unrealistic as an option.  I looked at the cost of pulling in and selectively compiling (libs) an entire boost 1.6, and that went a lot easier (added less than a minute to my build time).
>
> Matt
>
> ----- Original Message -----
> > From: "Sage Weil" <sweil@redhat.com>
> > To: "Allen Samuels" <Allen.Samuels@sandisk.com>
> > Cc: ceph-devel@vger.kernel.org, mbenjami@redhat.com, cbodley@redhat.com
> > Sent: Wednesday, February 3, 2016 3:04:57 PM
> > Subject: Re: inline vector container
> >
> > On Wed, 3 Feb 2016, Allen Samuels wrote:
> > > One thing that the code base needs is a simple vector container that is
> > > optimized for a small number of elements, i.e., for small element counts we
> > > avoid the malloc/free overhead. But fully supports being resized into
> > > larger
> > > containers that are unbounded. Of course it will need to follow all of the
> > > proper object copy/move semantics so that things like unique_ptr, etc work
> > > correctly.
> > >
> > > I heard rumors that there was one available in the boost world, but I can’t
> > > seem to find it. Do you know about one being available?
> >
> > http://www.boost.org/doc/libs/1_60_0/doc/html/boost/container/small_vector.html


The fb / folly code also has a small vector:
https://github.com/facebook/folly/blob/master/folly/small_vector.h
that used a C++11 move semantics whenever possible. Compared other
parts of folly this has pretty small dependencies on folly and those
can prob be ripped out.

>
>
> >
> > > I’ve been prototyping one myself, just to get re-familiar with all of the
> > > C++11 move sementics, and trivial constructors, etc.
> > >
> > > The code is pretty complete, but the testing gets rather involved. There’s
> > > no reason to contain this if it’s available elsewhere. But if it isn’t I
> > > plan on continuing this…
> >
> > I think Casey had prototyped something similar using a custom allocator,
> > too, but I didn't actually look at the result.  And Matt talked about just
> > pulling the boost one in-tree until we get updated boost in the supported
> > distros, but I forget if he ran into problems there or not...
> >
> > sage
>
> --
> --
> Matt Benjamin
> Red Hat, Inc.
> 315 West Huron Street, Suite 140A
> Ann Arbor, Michigan 48103
>
> http://www.redhat.com/en/technologies/storage
>
> tel.  734-707-0660
> fax.  734-769-8938
> cel.  734-216-5309
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html




-- 
Milosz Tanski
CTO
16 East 34th Street, 15th floor
New York, NY 10016

p: 646-253-9055
e: milosz@adfin.com
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: inline vector container

[Matt Benjamin]

Yeah, that looks a lot more reasonable if we must split it out, though I would prefer boost.

Matt

----- Original Message -----
> From: "Milosz Tanski" <milosz@adfin.com>
> To: "Matt Benjamin" <mbenjamin@redhat.com>
> Cc: "Sage Weil" <sweil@redhat.com>, "Allen Samuels" <Allen.Samuels@sandisk.com>, "ceph-devel"
> <ceph-devel@vger.kernel.org>, cbodley@redhat.com
> Sent: Wednesday, February 3, 2016 4:21:12 PM
> Subject: Re: inline vector container
> 
> On Wed, Feb 3, 2016 at 3:57 PM, Matt Benjamin <mbenjamin@redhat.com> wrote:
> >
> > Hi,
> >
> > I think we should go with small_vector for this role, yes.  I found two
> > issues.  First, there are critical defects in small_vector prior to boost
> > 1.6.0.  Second, though it is header-only, the coupling with related
> > version-specific boost types (container, allocator, respective detail
> > types, and platform-specific selectors...) seems to make pulling it in
> > separately pretty unrealistic as an option.  I looked at the cost of
> > pulling in and selectively compiling (libs) an entire boost 1.6, and that
> > went a lot easier (added less than a minute to my build time).
> >
> > Matt
> >
> > ----- Original Message -----
> > > From: "Sage Weil" <sweil@redhat.com>
> > > To: "Allen Samuels" <Allen.Samuels@sandisk.com>
> > > Cc: ceph-devel@vger.kernel.org, mbenjami@redhat.com, cbodley@redhat.com
> > > Sent: Wednesday, February 3, 2016 3:04:57 PM
> > > Subject: Re: inline vector container
> > >
> > > On Wed, 3 Feb 2016, Allen Samuels wrote:
> > > > One thing that the code base needs is a simple vector container that is
> > > > optimized for a small number of elements, i.e., for small element
> > > > counts we
> > > > avoid the malloc/free overhead. But fully supports being resized into
> > > > larger
> > > > containers that are unbounded. Of course it will need to follow all of
> > > > the
> > > > proper object copy/move semantics so that things like unique_ptr, etc
> > > > work
> > > > correctly.
> > > >
> > > > I heard rumors that there was one available in the boost world, but I
> > > > can’t
> > > > seem to find it. Do you know about one being available?
> > >
> > > http://www.boost.org/doc/libs/1_60_0/doc/html/boost/container/small_vector.html
> 
> 
> The fb / folly code also has a small vector:
> https://github.com/facebook/folly/blob/master/folly/small_vector.h
> that used a C++11 move semantics whenever possible. Compared other
> parts of folly this has pretty small dependencies on folly and those
> can prob be ripped out.
> 
> >
> >
> > >
> > > > I’ve been prototyping one myself, just to get re-familiar with all of
> > > > the
> > > > C++11 move sementics, and trivial constructors, etc.
> > > >
> > > > The code is pretty complete, but the testing gets rather involved.
> > > > There’s
> > > > no reason to contain this if it’s available elsewhere. But if it isn’t
> > > > I
> > > > plan on continuing this…
> > >
> > > I think Casey had prototyped something similar using a custom allocator,
> > > too, but I didn't actually look at the result.  And Matt talked about
> > > just
> > > pulling the boost one in-tree until we get updated boost in the supported
> > > distros, but I forget if he ran into problems there or not...
> > >
> > > sage
> >
> > --
> > --
> > Matt Benjamin
> > Red Hat, Inc.
> > 315 West Huron Street, Suite 140A
> > Ann Arbor, Michigan 48103
> >
> > http://www.redhat.com/en/technologies/storage
> >
> > tel.  734-707-0660
> > fax.  734-769-8938
> > cel.  734-216-5309
> > --
> > To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 
> 
> 
> --
> Milosz Tanski
> CTO
> 16 East 34th Street, 15th floor
> New York, NY 10016
> 
> p: 646-253-9055
> e: milosz@adfin.com
> 

-- 
-- 
Matt Benjamin
Red Hat, Inc.
315 West Huron Street, Suite 140A
Ann Arbor, Michigan 48103

http://www.redhat.com/en/technologies/storage

tel.  734-707-0660
fax.  734-769-8938
cel.  734-216-5309
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: inline vector container

[Casey Bodley]

Hi Allen,

I did spend some time a couple months ago experimenting with a custom allocator
with inline storage for standard containers. You can find my branch on github
at https://github.com/cbodley/ceph/commits/wip-preallocator.

I was aiming for a general solution that worked with non-contiguous containers,
but couldn't find a good way to handle deallocations. So the approach was really
only a good fit for std::vector.

I also had trouble getting it to do the right thing with the copy and move
operators. I found that it was trying to use the new allocator to release memory
that came from the old allocator. Presumably there's a way to make this work
using std::allocator_traits; have you had better luck here? I'd love to see your
prototype.

I tend to agree that we should go with the boost solution if we can. But if
a) we can't use boost::small_vector in the near-term due to versioning, and
b) we can get a custom version tested and working, it might be worth pursuing.

Casey

----- Original Message -----
> Hi,
> 
> I think we should go with small_vector for this role, yes.  I found two
> issues.  First, there are critical defects in small_vector prior to boost
> 1.6.0.  Second, though it is header-only, the coupling with related
> version-specific boost types (container, allocator, respective detail types,
> and platform-specific selectors...) seems to make pulling it in separately
> pretty unrealistic as an option.  I looked at the cost of pulling in and
> selectively compiling (libs) an entire boost 1.6, and that went a lot easier
> (added less than a minute to my build time).
> 
> Matt
> 
> ----- Original Message -----
> > From: "Sage Weil" <sweil@redhat.com>
> > To: "Allen Samuels" <Allen.Samuels@sandisk.com>
> > Cc: ceph-devel@vger.kernel.org, mbenjami@redhat.com, cbodley@redhat.com
> > Sent: Wednesday, February 3, 2016 3:04:57 PM
> > Subject: Re: inline vector container
> > 
> > On Wed, 3 Feb 2016, Allen Samuels wrote:
> > > One thing that the code base needs is a simple vector container that is
> > > optimized for a small number of elements, i.e., for small element counts
> > > we
> > > avoid the malloc/free overhead. But fully supports being resized into
> > > larger
> > > containers that are unbounded. Of course it will need to follow all of
> > > the
> > > proper object copy/move semantics so that things like unique_ptr, etc
> > > work
> > > correctly.
> > > 
> > > I heard rumors that there was one available in the boost world, but I
> > > can’t
> > > seem to find it. Do you know about one being available?
> > 
> > http://www.boost.org/doc/libs/1_60_0/doc/html/boost/container/small_vector.html
> > 
> > > I’ve been prototyping one myself, just to get re-familiar with all of the
> > > C++11 move sementics, and trivial constructors, etc.
> > > 
> > > The code is pretty complete, but the testing gets rather involved.
> > > There’s
> > > no reason to contain this if it’s available elsewhere. But if it isn’t I
> > > plan on continuing this…
> > 
> > I think Casey had prototyped something similar using a custom allocator,
> > too, but I didn't actually look at the result.  And Matt talked about just
> > pulling the boost one in-tree until we get updated boost in the supported
> > distros, but I forget if he ran into problems there or not...
> > 
> > sage
> 
> --
> --
> Matt Benjamin
> Red Hat, Inc.
> 315 West Huron Street, Suite 140A
> Ann Arbor, Michigan 48103
> 
> http://www.redhat.com/en/technologies/storage
> 
> tel.  734-707-0660
> fax.  734-769-8938
> cel.  734-216-5309
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: inline vector container

[Allen Samuels]

I would say that just pulling the latest boost into the tree and using it for builds is the best path forward. But I'm in no way competent to make that kind of change in the build system -- especially during the automake cmake changeover period.


Allen Samuels
Software Architect, Fellow, Systems and Software Solutions

2880 Junction Avenue, San Jose, CA 95134
T: +1 408 801 7030| M: +1 408 780 6416
allen.samuels@SanDisk.com


-----Original Message-----
From: Casey Bodley [mailto:cbodley@redhat.com]
Sent: Wednesday, February 03, 2016 1:26 PM
To: Matt Benjamin <mbenjamin@redhat.com>
Cc: Sage Weil <sweil@redhat.com>; Allen Samuels <Allen.Samuels@sandisk.com>; ceph-devel@vger.kernel.org
Subject: Re: inline vector container

Hi Allen,

I did spend some time a couple months ago experimenting with a custom allocator with inline storage for standard containers. You can find my branch on github at https://github.com/cbodley/ceph/commits/wip-preallocator.

I was aiming for a general solution that worked with non-contiguous containers, but couldn't find a good way to handle deallocations. So the approach was really only a good fit for std::vector.

I also had trouble getting it to do the right thing with the copy and move operators. I found that it was trying to use the new allocator to release memory that came from the old allocator. Presumably there's a way to make this work using std::allocator_traits; have you had better luck here? I'd love to see your prototype.

I tend to agree that we should go with the boost solution if we can. But if
a) we can't use boost::small_vector in the near-term due to versioning, and
b) we can get a custom version tested and working, it might be worth pursuing.

Casey

----- Original Message -----
> Hi,
>
> I think we should go with small_vector for this role, yes.  I found
> two issues.  First, there are critical defects in small_vector prior
> to boost 1.6.0.  Second, though it is header-only, the coupling with
> related version-specific boost types (container, allocator, respective
> detail types, and platform-specific selectors...) seems to make
> pulling it in separately pretty unrealistic as an option.  I looked at
> the cost of pulling in and selectively compiling (libs) an entire
> boost 1.6, and that went a lot easier (added less than a minute to my build time).
>
> Matt
>
> ----- Original Message -----
> > From: "Sage Weil" <sweil@redhat.com>
> > To: "Allen Samuels" <Allen.Samuels@sandisk.com>
> > Cc: ceph-devel@vger.kernel.org, mbenjami@redhat.com,
> > cbodley@redhat.com
> > Sent: Wednesday, February 3, 2016 3:04:57 PM
> > Subject: Re: inline vector container
> >
> > On Wed, 3 Feb 2016, Allen Samuels wrote:
> > > One thing that the code base needs is a simple vector container
> > > that is optimized for a small number of elements, i.e., for small
> > > element counts we avoid the malloc/free overhead. But fully
> > > supports being resized into larger containers that are unbounded.
> > > Of course it will need to follow all of the proper object
> > > copy/move semantics so that things like unique_ptr, etc work
> > > correctly.
> > >
> > > I heard rumors that there was one available in the boost world,
> > > but I can’t seem to find it. Do you know about one being
> > > available?
> >
> > http://www.boost.org/doc/libs/1_60_0/doc/html/boost/container/small_
> > vector.html
> >
> > > I’ve been prototyping one myself, just to get re-familiar with all
> > > of the
> > > C++11 move sementics, and trivial constructors, etc.
> > >
> > > The code is pretty complete, but the testing gets rather involved.
> > > There’s
> > > no reason to contain this if it’s available elsewhere. But if it
> > > isn’t I plan on continuing this…
> >
> > I think Casey had prototyped something similar using a custom
> > allocator, too, but I didn't actually look at the result.  And Matt
> > talked about just pulling the boost one in-tree until we get updated
> > boost in the supported distros, but I forget if he ran into problems there or not...
> >
> > sage
>
> --
> --
> Matt Benjamin
> Red Hat, Inc.
> 315 West Huron Street, Suite 140A
> Ann Arbor, Michigan 48103
>
> http://www.redhat.com/en/technologies/storage
>
> tel.  734-707-0660
> fax.  734-769-8938
> cel.  734-216-5309
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel"
> in the body of a message to majordomo@vger.kernel.org More majordomo
> info at  http://vger.kernel.org/majordomo-info.html
>
PLEASE NOTE: The information contained in this electronic mail message is intended only for the use of the designated recipient(s) named above. If the reader of this message is not the intended recipient, you are hereby notified that you have received this message in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify the sender by telephone or e-mail (as shown above) immediately and destroy any and all copies of this message in your possession (whether hard copies or electronically stored copies).

Re: inline vector container

[Matt Benjamin]

I'll prioritize this.  Using more of folly may be a worthy project as well, but that can wait for later... :)

tx!

Matt

----- Original Message -----
> From: "Allen Samuels" <Allen.Samuels@sandisk.com>
> To: "Casey Bodley" <cbodley@redhat.com>, "Matt Benjamin" <mbenjamin@redhat.com>
> Cc: "Sage Weil" <sweil@redhat.com>, ceph-devel@vger.kernel.org
> Sent: Wednesday, February 3, 2016 5:06:57 PM
> Subject: RE: inline vector container
> 
> I would say that just pulling the latest boost into the tree and using it for
> builds is the best path forward. But I'm in no way competent to make that
> kind of change in the build system -- especially during the automake cmake
> changeover period.
> 
> 
> Allen Samuels
> Software Architect, Fellow, Systems and Software Solutions
> 
> 2880 Junction Avenue, San Jose, CA 95134
> T: +1 408 801 7030| M: +1 408 780 6416
> allen.samuels@SanDisk.com
> 
> 
> -----Original Message-----
> From: Casey Bodley [mailto:cbodley@redhat.com]
> Sent: Wednesday, February 03, 2016 1:26 PM
> To: Matt Benjamin <mbenjamin@redhat.com>
> Cc: Sage Weil <sweil@redhat.com>; Allen Samuels <Allen.Samuels@sandisk.com>;
> ceph-devel@vger.kernel.org
> Subject: Re: inline vector container
> 
> Hi Allen,
> 
> I did spend some time a couple months ago experimenting with a custom
> allocator with inline storage for standard containers. You can find my
> branch on github at
> https://github.com/cbodley/ceph/commits/wip-preallocator.
> 
> I was aiming for a general solution that worked with non-contiguous
> containers, but couldn't find a good way to handle deallocations. So the
> approach was really only a good fit for std::vector.
> 
> I also had trouble getting it to do the right thing with the copy and move
> operators. I found that it was trying to use the new allocator to release
> memory that came from the old allocator. Presumably there's a way to make
> this work using std::allocator_traits; have you had better luck here? I'd
> love to see your prototype.
> 
> I tend to agree that we should go with the boost solution if we can. But if
> a) we can't use boost::small_vector in the near-term due to versioning, and
> b) we can get a custom version tested and working, it might be worth
> pursuing.
> 
> Casey
> 
> ----- Original Message -----
> > Hi,
> >
> > I think we should go with small_vector for this role, yes.  I found
> > two issues.  First, there are critical defects in small_vector prior
> > to boost 1.6.0.  Second, though it is header-only, the coupling with
> > related version-specific boost types (container, allocator, respective
> > detail types, and platform-specific selectors...) seems to make
> > pulling it in separately pretty unrealistic as an option.  I looked at
> > the cost of pulling in and selectively compiling (libs) an entire
> > boost 1.6, and that went a lot easier (added less than a minute to my build
> > time).
> >
> > Matt
> >
> > ----- Original Message -----
> > > From: "Sage Weil" <sweil@redhat.com>
> > > To: "Allen Samuels" <Allen.Samuels@sandisk.com>
> > > Cc: ceph-devel@vger.kernel.org, mbenjami@redhat.com,
> > > cbodley@redhat.com
> > > Sent: Wednesday, February 3, 2016 3:04:57 PM
> > > Subject: Re: inline vector container
> > >
> > > On Wed, 3 Feb 2016, Allen Samuels wrote:
> > > > One thing that the code base needs is a simple vector container
> > > > that is optimized for a small number of elements, i.e., for small
> > > > element counts we avoid the malloc/free overhead. But fully
> > > > supports being resized into larger containers that are unbounded.
> > > > Of course it will need to follow all of the proper object
> > > > copy/move semantics so that things like unique_ptr, etc work
> > > > correctly.
> > > >
> > > > I heard rumors that there was one available in the boost world,
> > > > but I can’t seem to find it. Do you know about one being
> > > > available?
> > >
> > > http://www.boost.org/doc/libs/1_60_0/doc/html/boost/container/small_
> > > vector.html
> > >
> > > > I’ve been prototyping one myself, just to get re-familiar with all
> > > > of the
> > > > C++11 move sementics, and trivial constructors, etc.
> > > >
> > > > The code is pretty complete, but the testing gets rather involved.
> > > > There’s
> > > > no reason to contain this if it’s available elsewhere. But if it
> > > > isn’t I plan on continuing this…
> > >
> > > I think Casey had prototyped something similar using a custom
> > > allocator, too, but I didn't actually look at the result.  And Matt
> > > talked about just pulling the boost one in-tree until we get updated
> > > boost in the supported distros, but I forget if he ran into problems
> > > there or not...
> > >
> > > sage
> >
> > --
> > --
> > Matt Benjamin
> > Red Hat, Inc.
> > 315 West Huron Street, Suite 140A
> > Ann Arbor, Michigan 48103
> >
> > http://www.redhat.com/en/technologies/storage
> >
> > tel.  734-707-0660
> > fax.  734-769-8938
> > cel.  734-216-5309
> > --
> > To unsubscribe from this list: send the line "unsubscribe ceph-devel"
> > in the body of a message to majordomo@vger.kernel.org More majordomo
> > info at  http://vger.kernel.org/majordomo-info.html
> >
> PLEASE NOTE: The information contained in this electronic mail message is
> intended only for the use of the designated recipient(s) named above. If the
> reader of this message is not the intended recipient, you are hereby
> notified that you have received this message in error and that any review,
> dissemination, distribution, or copying of this message is strictly
> prohibited. If you have received this communication in error, please notify
> the sender by telephone or e-mail (as shown above) immediately and destroy
> any and all copies of this message in your possession (whether hard copies
> or electronically stored copies).
> 

-- 
-- 
Matt Benjamin
Red Hat, Inc.
315 West Huron Street, Suite 140A
Ann Arbor, Michigan 48103

http://www.redhat.com/en/technologies/storage

tel.  734-707-0660
fax.  734-769-8938
cel.  734-216-5309
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: inline vector container

[Willem Jan Withagen]

On 3-2-2016 23:10, Matt Benjamin wrote:
> I'll prioritize this.  Using more of folly may be a worthy project as well, but that can wait for later... :)

Hi Matt,

Can you give me a URL for the folly stuff.
Since I cannot find any reference to it in the FreeBSD ports.

I think I'd otherwise prefer Boost, since the ports already contains a
fair amount of Boost stuff.

Currently I have installed:
boost-all-1.55.0      The "meta-port" for boost libraries
boost-docs-1.55.0     Documentation for libraries from boost.org
boost-jam-1.55.0      Build tool from the boost.org
boost-libs-1.55.0_9   Free portable C++ libraries (without Boost.Python)

But I see that the new ports have migrated to:
/usr/ports/devel/boost_build/Makefile:PORTVERSION=      2.0.m12

So that would move it beyond 1.6, I presume.

--WjW


> tx!
> 
> Matt
> 
> ----- Original Message -----
>> From: "Allen Samuels" <Allen.Samuels@sandisk.com>
>> To: "Casey Bodley" <cbodley@redhat.com>, "Matt Benjamin" <mbenjamin@redhat.com>
>> Cc: "Sage Weil" <sweil@redhat.com>, ceph-devel@vger.kernel.org
>> Sent: Wednesday, February 3, 2016 5:06:57 PM
>> Subject: RE: inline vector container
>>
>> I would say that just pulling the latest boost into the tree and using it for
>> builds is the best path forward. But I'm in no way competent to make that
>> kind of change in the build system -- especially during the automake cmake
>> changeover period.
>>
>>
>> Allen Samuels
>> Software Architect, Fellow, Systems and Software Solutions
>>
>> 2880 Junction Avenue, San Jose, CA 95134
>> T: +1 408 801 7030| M: +1 408 780 6416
>> allen.samuels@SanDisk.com
>>
>>
>> -----Original Message-----
>> From: Casey Bodley [mailto:cbodley@redhat.com]
>> Sent: Wednesday, February 03, 2016 1:26 PM
>> To: Matt Benjamin <mbenjamin@redhat.com>
>> Cc: Sage Weil <sweil@redhat.com>; Allen Samuels <Allen.Samuels@sandisk.com>;
>> ceph-devel@vger.kernel.org
>> Subject: Re: inline vector container
>>
>> Hi Allen,
>>
>> I did spend some time a couple months ago experimenting with a custom
>> allocator with inline storage for standard containers. You can find my
>> branch on github at
>> https://github.com/cbodley/ceph/commits/wip-preallocator.
>>
>> I was aiming for a general solution that worked with non-contiguous
>> containers, but couldn't find a good way to handle deallocations. So the
>> approach was really only a good fit for std::vector.
>>
>> I also had trouble getting it to do the right thing with the copy and move
>> operators. I found that it was trying to use the new allocator to release
>> memory that came from the old allocator. Presumably there's a way to make
>> this work using std::allocator_traits; have you had better luck here? I'd
>> love to see your prototype.
>>
>> I tend to agree that we should go with the boost solution if we can. But if
>> a) we can't use boost::small_vector in the near-term due to versioning, and
>> b) we can get a custom version tested and working, it might be worth
>> pursuing.
>>
>> Casey
>>
>> ----- Original Message -----
>>> Hi,
>>>
>>> I think we should go with small_vector for this role, yes.  I found
>>> two issues.  First, there are critical defects in small_vector prior
>>> to boost 1.6.0.  Second, though it is header-only, the coupling with
>>> related version-specific boost types (container, allocator, respective
>>> detail types, and platform-specific selectors...) seems to make
>>> pulling it in separately pretty unrealistic as an option.  I looked at
>>> the cost of pulling in and selectively compiling (libs) an entire
>>> boost 1.6, and that went a lot easier (added less than a minute to my build
>>> time).
>>>
>>> Matt
>>>
>>> ----- Original Message -----
>>>> From: "Sage Weil" <sweil@redhat.com>
>>>> To: "Allen Samuels" <Allen.Samuels@sandisk.com>
>>>> Cc: ceph-devel@vger.kernel.org, mbenjami@redhat.com,
>>>> cbodley@redhat.com
>>>> Sent: Wednesday, February 3, 2016 3:04:57 PM
>>>> Subject: Re: inline vector container
>>>>
>>>> On Wed, 3 Feb 2016, Allen Samuels wrote:
>>>>> One thing that the code base needs is a simple vector container
>>>>> that is optimized for a small number of elements, i.e., for small
>>>>> element counts we avoid the malloc/free overhead. But fully
>>>>> supports being resized into larger containers that are unbounded.
>>>>> Of course it will need to follow all of the proper object
>>>>> copy/move semantics so that things like unique_ptr, etc work
>>>>> correctly.
>>>>>
>>>>> I heard rumors that there was one available in the boost world,
>>>>> but I can’t seem to find it. Do you know about one being
>>>>> available?
>>>>
>>>> http://www.boost.org/doc/libs/1_60_0/doc/html/boost/container/small_
>>>> vector.html
>>>>
>>>>> I’ve been prototyping one myself, just to get re-familiar with all
>>>>> of the
>>>>> C++11 move sementics, and trivial constructors, etc.
>>>>>
>>>>> The code is pretty complete, but the testing gets rather involved.
>>>>> There’s
>>>>> no reason to contain this if it’s available elsewhere. But if it
>>>>> isn’t I plan on continuing this…
>>>>
>>>> I think Casey had prototyped something similar using a custom
>>>> allocator, too, but I didn't actually look at the result.  And Matt
>>>> talked about just pulling the boost one in-tree until we get updated
>>>> boost in the supported distros, but I forget if he ran into problems
>>>> there or not...
>>>>
>>>> sage
>>>
>>> --
>>> --
>>> Matt Benjamin
>>> Red Hat, Inc.
>>> 315 West Huron Street, Suite 140A
>>> Ann Arbor, Michigan 48103
>>>
>>> http://www.redhat.com/en/technologies/storage
>>>
>>> tel.  734-707-0660
>>> fax.  734-769-8938
>>> cel.  734-216-5309
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe ceph-devel"
>>> in the body of a message to majordomo@vger.kernel.org More majordomo
>>> info at  http://vger.kernel.org/majordomo-info.html
>>>
>> PLEASE NOTE: The information contained in this electronic mail message is
>> intended only for the use of the designated recipient(s) named above. If the
>> reader of this message is not the intended recipient, you are hereby
>> notified that you have received this message in error and that any review,
>> dissemination, distribution, or copying of this message is strictly
>> prohibited. If you have received this communication in error, please notify
>> the sender by telephone or e-mail (as shown above) immediately and destroy
>> any and all copies of this message in your possession (whether hard copies
>> or electronically stored copies).
>>
> 

--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: inline vector container

[Matt Benjamin]

Hi Willem,

Milosz pasted a file inline.  Facebook's upstream repo is https://github.com/facebook/folly (Mr. Google), but what I was agreeing is, for the present, if we can't realize boost small_vector, we might adapt just that type from Folly for the short term (that was Milosz meaning, in this thread).

(So don't panic ;)

Matt

----- Original Message -----
> From: "Willem Jan Withagen" <wjw@digiware.nl>
> To: "Matt Benjamin" <mbenjamin@redhat.com>, "Allen Samuels" <Allen.Samuels@sandisk.com>
> Cc: "Casey Bodley" <cbodley@redhat.com>, "Sage Weil" <sweil@redhat.com>, ceph-devel@vger.kernel.org
> Sent: Thursday, February 4, 2016 7:06:14 AM
> Subject: Re: inline vector container
> 
> On 3-2-2016 23:10, Matt Benjamin wrote:
> > I'll prioritize this.  Using more of folly may be a worthy project as well,
> > but that can wait for later... :)
> 
> Hi Matt,
> 
> Can you give me a URL for the folly stuff.
> Since I cannot find any reference to it in the FreeBSD ports.
> 
> I think I'd otherwise prefer Boost, since the ports already contains a
> fair amount of Boost stuff.
> 
> Currently I have installed:
> boost-all-1.55.0      The "meta-port" for boost libraries
> boost-docs-1.55.0     Documentation for libraries from boost.org
> boost-jam-1.55.0      Build tool from the boost.org
> boost-libs-1.55.0_9   Free portable C++ libraries (without Boost.Python)
> 
> But I see that the new ports have migrated to:
> /usr/ports/devel/boost_build/Makefile:PORTVERSION=      2.0.m12
> 
> So that would move it beyond 1.6, I presume.
> 
> --WjW
> 
> 
> > tx!
> > 
> > Matt
> > 
> > ----- Original Message -----
> >> From: "Allen Samuels" <Allen.Samuels@sandisk.com>
> >> To: "Casey Bodley" <cbodley@redhat.com>, "Matt Benjamin"
> >> <mbenjamin@redhat.com>
> >> Cc: "Sage Weil" <sweil@redhat.com>, ceph-devel@vger.kernel.org
> >> Sent: Wednesday, February 3, 2016 5:06:57 PM
> >> Subject: RE: inline vector container
> >>
> >> I would say that just pulling the latest boost into the tree and using it
> >> for
> >> builds is the best path forward. But I'm in no way competent to make that
> >> kind of change in the build system -- especially during the automake cmake
> >> changeover period.
> >>
> >>
> >> Allen Samuels
> >> Software Architect, Fellow, Systems and Software Solutions
> >>
> >> 2880 Junction Avenue, San Jose, CA 95134
> >> T: +1 408 801 7030| M: +1 408 780 6416
> >> allen.samuels@SanDisk.com
> >>
> >>
> >> -----Original Message-----
> >> From: Casey Bodley [mailto:cbodley@redhat.com]
> >> Sent: Wednesday, February 03, 2016 1:26 PM
> >> To: Matt Benjamin <mbenjamin@redhat.com>
> >> Cc: Sage Weil <sweil@redhat.com>; Allen Samuels
> >> <Allen.Samuels@sandisk.com>;
> >> ceph-devel@vger.kernel.org
> >> Subject: Re: inline vector container
> >>
> >> Hi Allen,
> >>
> >> I did spend some time a couple months ago experimenting with a custom
> >> allocator with inline storage for standard containers. You can find my
> >> branch on github at
> >> https://github.com/cbodley/ceph/commits/wip-preallocator.
> >>
> >> I was aiming for a general solution that worked with non-contiguous
> >> containers, but couldn't find a good way to handle deallocations. So the
> >> approach was really only a good fit for std::vector.
> >>
> >> I also had trouble getting it to do the right thing with the copy and move
> >> operators. I found that it was trying to use the new allocator to release
> >> memory that came from the old allocator. Presumably there's a way to make
> >> this work using std::allocator_traits; have you had better luck here? I'd
> >> love to see your prototype.
> >>
> >> I tend to agree that we should go with the boost solution if we can. But
> >> if
> >> a) we can't use boost::small_vector in the near-term due to versioning,
> >> and
> >> b) we can get a custom version tested and working, it might be worth
> >> pursuing.
> >>
> >> Casey
> >>
> >> ----- Original Message -----
> >>> Hi,
> >>>
> >>> I think we should go with small_vector for this role, yes.  I found
> >>> two issues.  First, there are critical defects in small_vector prior
> >>> to boost 1.6.0.  Second, though it is header-only, the coupling with
> >>> related version-specific boost types (container, allocator, respective
> >>> detail types, and platform-specific selectors...) seems to make
> >>> pulling it in separately pretty unrealistic as an option.  I looked at
> >>> the cost of pulling in and selectively compiling (libs) an entire
> >>> boost 1.6, and that went a lot easier (added less than a minute to my
> >>> build
> >>> time).
> >>>
> >>> Matt
> >>>
> >>> ----- Original Message -----
> >>>> From: "Sage Weil" <sweil@redhat.com>
> >>>> To: "Allen Samuels" <Allen.Samuels@sandisk.com>
> >>>> Cc: ceph-devel@vger.kernel.org, mbenjami@redhat.com,
> >>>> cbodley@redhat.com
> >>>> Sent: Wednesday, February 3, 2016 3:04:57 PM
> >>>> Subject: Re: inline vector container
> >>>>
> >>>> On Wed, 3 Feb 2016, Allen Samuels wrote:
> >>>>> One thing that the code base needs is a simple vector container
> >>>>> that is optimized for a small number of elements, i.e., for small
> >>>>> element counts we avoid the malloc/free overhead. But fully
> >>>>> supports being resized into larger containers that are unbounded.
> >>>>> Of course it will need to follow all of the proper object
> >>>>> copy/move semantics so that things like unique_ptr, etc work
> >>>>> correctly.
> >>>>>
> >>>>> I heard rumors that there was one available in the boost world,
> >>>>> but I can’t seem to find it. Do you know about one being
> >>>>> available?
> >>>>
> >>>> http://www.boost.org/doc/libs/1_60_0/doc/html/boost/container/small_
> >>>> vector.html
> >>>>
> >>>>> I’ve been prototyping one myself, just to get re-familiar with all
> >>>>> of the
> >>>>> C++11 move sementics, and trivial constructors, etc.
> >>>>>
> >>>>> The code is pretty complete, but the testing gets rather involved.
> >>>>> There’s
> >>>>> no reason to contain this if it’s available elsewhere. But if it
> >>>>> isn’t I plan on continuing this…
> >>>>
> >>>> I think Casey had prototyped something similar using a custom
> >>>> allocator, too, but I didn't actually look at the result.  And Matt
> >>>> talked about just pulling the boost one in-tree until we get updated
> >>>> boost in the supported distros, but I forget if he ran into problems
> >>>> there or not...
> >>>>
> >>>> sage
> >>>
> >>> --
> >>> --
> >>> Matt Benjamin
> >>> Red Hat, Inc.
> >>> 315 West Huron Street, Suite 140A
> >>> Ann Arbor, Michigan 48103
> >>>
> >>> http://www.redhat.com/en/technologies/storage
> >>>
> >>> tel.  734-707-0660
> >>> fax.  734-769-8938
> >>> cel.  734-216-5309
> >>> --
> >>> To unsubscribe from this list: send the line "unsubscribe ceph-devel"
> >>> in the body of a message to majordomo@vger.kernel.org More majordomo
> >>> info at  http://vger.kernel.org/majordomo-info.html
> >>>
> >> PLEASE NOTE: The information contained in this electronic mail message is
> >> intended only for the use of the designated recipient(s) named above. If
> >> the
> >> reader of this message is not the intended recipient, you are hereby
> >> notified that you have received this message in error and that any review,
> >> dissemination, distribution, or copying of this message is strictly
> >> prohibited. If you have received this communication in error, please
> >> notify
> >> the sender by telephone or e-mail (as shown above) immediately and destroy
> >> any and all copies of this message in your possession (whether hard copies
> >> or electronically stored copies).
> >>
> > 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

-- 
-- 
Matt Benjamin
Red Hat, Inc.
315 West Huron Street, Suite 140A
Ann Arbor, Michigan 48103

http://www.redhat.com/en/technologies/storage

tel.  734-707-0660
fax.  734-769-8938
cel.  734-216-5309
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: inline vector container

[Willem Jan Withagen]

On 4-2-2016 15:42, Matt Benjamin wrote:
> Hi Willem,
> 
> Milosz pasted a file inline.  Facebook's upstream repo is
> https://github.com/facebook/folly (Mr. Google), but what I was
> agreeing is, for the present, if we can't realize boost small_vector,
> we might adapt just that type from Folly for the short term (that was
> Milosz meaning, in this thread).
> 
> (So don't panic ;)

It'll take a bit more to panic, but it would be a shame if we have to
port something for the intermediate 2-times. And then to only throw it
out a bit later.

Where I still have to look at "trivia" like AIO, and RBD...

Although my main interest is to get RBD in the freebsd guest DOM's
running, especially bhyve. So I hope that that is going to be a bit less
convoluted than writting a RBD device in the kernel. Especially since
only recently I saw patches to add VirtFS to the bhyve virt-io infra.

--WjW

> 
> Matt
> 
> ----- Original Message -----
>> From: "Willem Jan Withagen" <wjw@digiware.nl> To: "Matt Benjamin"
>> <mbenjamin@redhat.com>, "Allen Samuels"
>> <Allen.Samuels@sandisk.com> Cc: "Casey Bodley"
>> <cbodley@redhat.com>, "Sage Weil" <sweil@redhat.com>,
>> ceph-devel@vger.kernel.org Sent: Thursday, February 4, 2016 7:06:14
>> AM Subject: Re: inline vector container
>> 
>> On 3-2-2016 23:10, Matt Benjamin wrote:
>>> I'll prioritize this.  Using more of folly may be a worthy
>>> project as well, but that can wait for later... :)
>> 
>> Hi Matt,
>> 
>> Can you give me a URL for the folly stuff. Since I cannot find any
>> reference to it in the FreeBSD ports.
>> 
>> I think I'd otherwise prefer Boost, since the ports already
>> contains a fair amount of Boost stuff.
>> 
>> Currently I have installed: boost-all-1.55.0      The "meta-port"
>> for boost libraries boost-docs-1.55.0     Documentation for
>> libraries from boost.org boost-jam-1.55.0      Build tool from the
>> boost.org boost-libs-1.55.0_9   Free portable C++ libraries
>> (without Boost.Python)
>> 
>> But I see that the new ports have migrated to: 
>> /usr/ports/devel/boost_build/Makefile:PORTVERSION=      2.0.m12
>> 
>> So that would move it beyond 1.6, I presume.
>> 
>> --WjW
>> 
>> 
>>> tx!
>>> 
>>> Matt
>>> 
>>> ----- Original Message -----
>>>> From: "Allen Samuels" <Allen.Samuels@sandisk.com> To: "Casey
>>>> Bodley" <cbodley@redhat.com>, "Matt Benjamin" 
>>>> <mbenjamin@redhat.com> Cc: "Sage Weil" <sweil@redhat.com>,
>>>> ceph-devel@vger.kernel.org Sent: Wednesday, February 3, 2016
>>>> 5:06:57 PM Subject: RE: inline vector container
>>>> 
>>>> I would say that just pulling the latest boost into the tree
>>>> and using it for builds is the best path forward. But I'm in no
>>>> way competent to make that kind of change in the build system
>>>> -- especially during the automake cmake changeover period.
>>>> 
>>>> 
>>>> Allen Samuels Software Architect, Fellow, Systems and Software
>>>> Solutions
>>>> 
>>>> 2880 Junction Avenue, San Jose, CA 95134 T: +1 408 801 7030| M:
>>>> +1 408 780 6416 allen.samuels@SanDisk.com
>>>> 
>>>> 
>>>> -----Original Message----- From: Casey Bodley
>>>> [mailto:cbodley@redhat.com] Sent: Wednesday, February 03, 2016
>>>> 1:26 PM To: Matt Benjamin <mbenjamin@redhat.com> Cc: Sage Weil
>>>> <sweil@redhat.com>; Allen Samuels <Allen.Samuels@sandisk.com>; 
>>>> ceph-devel@vger.kernel.org Subject: Re: inline vector
>>>> container
>>>> 
>>>> Hi Allen,
>>>> 
>>>> I did spend some time a couple months ago experimenting with a
>>>> custom allocator with inline storage for standard containers.
>>>> You can find my branch on github at 
>>>> https://github.com/cbodley/ceph/commits/wip-preallocator.
>>>> 
>>>> I was aiming for a general solution that worked with
>>>> non-contiguous containers, but couldn't find a good way to
>>>> handle deallocations. So the approach was really only a good
>>>> fit for std::vector.
>>>> 
>>>> I also had trouble getting it to do the right thing with the
>>>> copy and move operators. I found that it was trying to use the
>>>> new allocator to release memory that came from the old
>>>> allocator. Presumably there's a way to make this work using
>>>> std::allocator_traits; have you had better luck here? I'd love
>>>> to see your prototype.
>>>> 
>>>> I tend to agree that we should go with the boost solution if we
>>>> can. But if a) we can't use boost::small_vector in the
>>>> near-term due to versioning, and b) we can get a custom version
>>>> tested and working, it might be worth pursuing.
>>>> 
>>>> Casey
>>>> 
>>>> ----- Original Message -----
>>>>> Hi,
>>>>> 
>>>>> I think we should go with small_vector for this role, yes.  I
>>>>> found two issues.  First, there are critical defects in
>>>>> small_vector prior to boost 1.6.0.  Second, though it is
>>>>> header-only, the coupling with related version-specific boost
>>>>> types (container, allocator, respective detail types, and
>>>>> platform-specific selectors...) seems to make pulling it in
>>>>> separately pretty unrealistic as an option.  I looked at the
>>>>> cost of pulling in and selectively compiling (libs) an
>>>>> entire boost 1.6, and that went a lot easier (added less than
>>>>> a minute to my build time).
>>>>> 
>>>>> Matt
>>>>> 
>>>>> ----- Original Message -----
>>>>>> From: "Sage Weil" <sweil@redhat.com> To: "Allen Samuels"
>>>>>> <Allen.Samuels@sandisk.com> Cc: ceph-devel@vger.kernel.org,
>>>>>> mbenjami@redhat.com, cbodley@redhat.com Sent: Wednesday,
>>>>>> February 3, 2016 3:04:57 PM Subject: Re: inline vector
>>>>>> container
>>>>>> 
>>>>>> On Wed, 3 Feb 2016, Allen Samuels wrote:
>>>>>>> One thing that the code base needs is a simple vector
>>>>>>> container that is optimized for a small number of
>>>>>>> elements, i.e., for small element counts we avoid the
>>>>>>> malloc/free overhead. But fully supports being resized
>>>>>>> into larger containers that are unbounded. Of course it
>>>>>>> will need to follow all of the proper object copy/move
>>>>>>> semantics so that things like unique_ptr, etc work 
>>>>>>> correctly.
>>>>>>> 
>>>>>>> I heard rumors that there was one available in the boost
>>>>>>> world, but I can’t seem to find it. Do you know about one
>>>>>>> being available?
>>>>>> 
>>>>>> http://www.boost.org/doc/libs/1_60_0/doc/html/boost/container/small_
>>>>>>
>>>>>> 
vector.html
>>>>>> 
>>>>>>> I’ve been prototyping one myself, just to get re-familiar
>>>>>>> with all of the C++11 move sementics, and trivial
>>>>>>> constructors, etc.
>>>>>>> 
>>>>>>> The code is pretty complete, but the testing gets rather
>>>>>>> involved. There’s no reason to contain this if it’s
>>>>>>> available elsewhere. But if it isn’t I plan on continuing
>>>>>>> this…
>>>>>> 
>>>>>> I think Casey had prototyped something similar using a
>>>>>> custom allocator, too, but I didn't actually look at the
>>>>>> result.  And Matt talked about just pulling the boost one
>>>>>> in-tree until we get updated boost in the supported
>>>>>> distros, but I forget if he ran into problems there or
>>>>>> not...
>>>>>> 
>>>>>> sage
>>>>> 
>>>>> -- -- Matt Benjamin Red Hat, Inc. 315 West Huron Street,
>>>>> Suite 140A Ann Arbor, Michigan 48103
>>>>> 
>>>>> http://www.redhat.com/en/technologies/storage
>>>>> 
>>>>> tel.  734-707-0660 fax.  734-769-8938 cel.  734-216-5309 -- 
>>>>> To unsubscribe from this list: send the line "unsubscribe
>>>>> ceph-devel" in the body of a message to
>>>>> majordomo@vger.kernel.org More majordomo info at
>>>>> http://vger.kernel.org/majordomo-info.html
>>>>> 
>>>> PLEASE NOTE: The information contained in this electronic mail
>>>> message is intended only for the use of the designated
>>>> recipient(s) named above. If the reader of this message is not
>>>> the intended recipient, you are hereby notified that you have
>>>> received this message in error and that any review, 
>>>> dissemination, distribution, or copying of this message is
>>>> strictly prohibited. If you have received this communication in
>>>> error, please notify the sender by telephone or e-mail (as
>>>> shown above) immediately and destroy any and all copies of this
>>>> message in your possession (whether hard copies or
>>>> electronically stored copies).
>>>> 
>>> 
>> 
>> -- To unsubscribe from this list: send the line "unsubscribe
>> ceph-devel" in the body of a message to majordomo@vger.kernel.org 
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> 
> 

--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: inline vector container

[Matt Benjamin]

Agree, we're all trying to avoid that.

Matt

----- Original Message -----
> From: "Willem Jan Withagen" <wjw@digiware.nl>
> To: "Matt Benjamin" <mbenjamin@redhat.com>
> Cc: "Allen Samuels" <Allen.Samuels@sandisk.com>, "Casey Bodley" <cbodley@redhat.com>, "Sage Weil" <sweil@redhat.com>,
> ceph-devel@vger.kernel.org
> Sent: Thursday, February 4, 2016 12:01:31 PM
> Subject: Re: inline vector container
> 
> On 4-2-2016 15:42, Matt Benjamin wrote:
> > Hi Willem,
> > 
> > Milosz pasted a file inline.  Facebook's upstream repo is
> > https://github.com/facebook/folly (Mr. Google), but what I was
> > agreeing is, for the present, if we can't realize boost small_vector,
> > we might adapt just that type from Folly for the short term (that was
> > Milosz meaning, in this thread).
> > 
> > (So don't panic ;)
> 
> It'll take a bit more to panic, but it would be a shame if we have to
> port something for the intermediate 2-times. And then to only throw it
> out a bit later.
> 
> Where I still have to look at "trivia" like AIO, and RBD...
> 
> Although my main interest is to get RBD in the freebsd guest DOM's
> running, especially bhyve. So I hope that that is going to be a bit less
> convoluted than writting a RBD device in the kernel. Especially since
> only recently I saw patches to add VirtFS to the bhyve virt-io infra.
> 
> --WjW
> 
> > 
> > Matt
> > 
> > ----- Original Message -----
> >> From: "Willem Jan Withagen" <wjw@digiware.nl> To: "Matt Benjamin"
> >> <mbenjamin@redhat.com>, "Allen Samuels"
> >> <Allen.Samuels@sandisk.com> Cc: "Casey Bodley"
> >> <cbodley@redhat.com>, "Sage Weil" <sweil@redhat.com>,
> >> ceph-devel@vger.kernel.org Sent: Thursday, February 4, 2016 7:06:14
> >> AM Subject: Re: inline vector container
> >> 
> >> On 3-2-2016 23:10, Matt Benjamin wrote:
> >>> I'll prioritize this.  Using more of folly may be a worthy
> >>> project as well, but that can wait for later... :)
> >> 
> >> Hi Matt,
> >> 
> >> Can you give me a URL for the folly stuff. Since I cannot find any
> >> reference to it in the FreeBSD ports.
> >> 
> >> I think I'd otherwise prefer Boost, since the ports already
> >> contains a fair amount of Boost stuff.
> >> 
> >> Currently I have installed: boost-all-1.55.0      The "meta-port"
> >> for boost libraries boost-docs-1.55.0     Documentation for
> >> libraries from boost.org boost-jam-1.55.0      Build tool from the
> >> boost.org boost-libs-1.55.0_9   Free portable C++ libraries
> >> (without Boost.Python)
> >> 
> >> But I see that the new ports have migrated to:
> >> /usr/ports/devel/boost_build/Makefile:PORTVERSION=      2.0.m12
> >> 
> >> So that would move it beyond 1.6, I presume.
> >> 
> >> --WjW
> >> 
> >> 
> >>> tx!
> >>> 
> >>> Matt
> >>> 
> >>> ----- Original Message -----
> >>>> From: "Allen Samuels" <Allen.Samuels@sandisk.com> To: "Casey
> >>>> Bodley" <cbodley@redhat.com>, "Matt Benjamin"
> >>>> <mbenjamin@redhat.com> Cc: "Sage Weil" <sweil@redhat.com>,
> >>>> ceph-devel@vger.kernel.org Sent: Wednesday, February 3, 2016
> >>>> 5:06:57 PM Subject: RE: inline vector container
> >>>> 
> >>>> I would say that just pulling the latest boost into the tree
> >>>> and using it for builds is the best path forward. But I'm in no
> >>>> way competent to make that kind of change in the build system
> >>>> -- especially during the automake cmake changeover period.
> >>>> 
> >>>> 
> >>>> Allen Samuels Software Architect, Fellow, Systems and Software
> >>>> Solutions
> >>>> 
> >>>> 2880 Junction Avenue, San Jose, CA 95134 T: +1 408 801 7030| M:
> >>>> +1 408 780 6416 allen.samuels@SanDisk.com
> >>>> 
> >>>> 
> >>>> -----Original Message----- From: Casey Bodley
> >>>> [mailto:cbodley@redhat.com] Sent: Wednesday, February 03, 2016
> >>>> 1:26 PM To: Matt Benjamin <mbenjamin@redhat.com> Cc: Sage Weil
> >>>> <sweil@redhat.com>; Allen Samuels <Allen.Samuels@sandisk.com>;
> >>>> ceph-devel@vger.kernel.org Subject: Re: inline vector
> >>>> container
> >>>> 
> >>>> Hi Allen,
> >>>> 
> >>>> I did spend some time a couple months ago experimenting with a
> >>>> custom allocator with inline storage for standard containers.
> >>>> You can find my branch on github at
> >>>> https://github.com/cbodley/ceph/commits/wip-preallocator.
> >>>> 
> >>>> I was aiming for a general solution that worked with
> >>>> non-contiguous containers, but couldn't find a good way to
> >>>> handle deallocations. So the approach was really only a good
> >>>> fit for std::vector.
> >>>> 
> >>>> I also had trouble getting it to do the right thing with the
> >>>> copy and move operators. I found that it was trying to use the
> >>>> new allocator to release memory that came from the old
> >>>> allocator. Presumably there's a way to make this work using
> >>>> std::allocator_traits; have you had better luck here? I'd love
> >>>> to see your prototype.
> >>>> 
> >>>> I tend to agree that we should go with the boost solution if we
> >>>> can. But if a) we can't use boost::small_vector in the
> >>>> near-term due to versioning, and b) we can get a custom version
> >>>> tested and working, it might be worth pursuing.
> >>>> 
> >>>> Casey
> >>>> 
> >>>> ----- Original Message -----
> >>>>> Hi,
> >>>>> 
> >>>>> I think we should go with small_vector for this role, yes.  I
> >>>>> found two issues.  First, there are critical defects in
> >>>>> small_vector prior to boost 1.6.0.  Second, though it is
> >>>>> header-only, the coupling with related version-specific boost
> >>>>> types (container, allocator, respective detail types, and
> >>>>> platform-specific selectors...) seems to make pulling it in
> >>>>> separately pretty unrealistic as an option.  I looked at the
> >>>>> cost of pulling in and selectively compiling (libs) an
> >>>>> entire boost 1.6, and that went a lot easier (added less than
> >>>>> a minute to my build time).
> >>>>> 
> >>>>> Matt
> >>>>> 
> >>>>> ----- Original Message -----
> >>>>>> From: "Sage Weil" <sweil@redhat.com> To: "Allen Samuels"
> >>>>>> <Allen.Samuels@sandisk.com> Cc: ceph-devel@vger.kernel.org,
> >>>>>> mbenjami@redhat.com, cbodley@redhat.com Sent: Wednesday,
> >>>>>> February 3, 2016 3:04:57 PM Subject: Re: inline vector
> >>>>>> container
> >>>>>> 
> >>>>>> On Wed, 3 Feb 2016, Allen Samuels wrote:
> >>>>>>> One thing that the code base needs is a simple vector
> >>>>>>> container that is optimized for a small number of
> >>>>>>> elements, i.e., for small element counts we avoid the
> >>>>>>> malloc/free overhead. But fully supports being resized
> >>>>>>> into larger containers that are unbounded. Of course it
> >>>>>>> will need to follow all of the proper object copy/move
> >>>>>>> semantics so that things like unique_ptr, etc work
> >>>>>>> correctly.
> >>>>>>> 
> >>>>>>> I heard rumors that there was one available in the boost
> >>>>>>> world, but I can’t seem to find it. Do you know about one
> >>>>>>> being available?
> >>>>>> 
> >>>>>> http://www.boost.org/doc/libs/1_60_0/doc/html/boost/container/small_
> >>>>>>
> >>>>>> 
> vector.html
> >>>>>> 
> >>>>>>> I’ve been prototyping one myself, just to get re-familiar
> >>>>>>> with all of the C++11 move sementics, and trivial
> >>>>>>> constructors, etc.
> >>>>>>> 
> >>>>>>> The code is pretty complete, but the testing gets rather
> >>>>>>> involved. There’s no reason to contain this if it’s
> >>>>>>> available elsewhere. But if it isn’t I plan on continuing
> >>>>>>> this…
> >>>>>> 
> >>>>>> I think Casey had prototyped something similar using a
> >>>>>> custom allocator, too, but I didn't actually look at the
> >>>>>> result.  And Matt talked about just pulling the boost one
> >>>>>> in-tree until we get updated boost in the supported
> >>>>>> distros, but I forget if he ran into problems there or
> >>>>>> not...
> >>>>>> 
> >>>>>> sage
> >>>>> 
> >>>>> -- -- Matt Benjamin Red Hat, Inc. 315 West Huron Street,
> >>>>> Suite 140A Ann Arbor, Michigan 48103
> >>>>> 
> >>>>> http://www.redhat.com/en/technologies/storage
> >>>>> 
> >>>>> tel.  734-707-0660 fax.  734-769-8938 cel.  734-216-5309 --
> >>>>> To unsubscribe from this list: send the line "unsubscribe
> >>>>> ceph-devel" in the body of a message to
> >>>>> majordomo@vger.kernel.org More majordomo info at
> >>>>> http://vger.kernel.org/majordomo-info.html
> >>>>> 
> >>>> PLEASE NOTE: The information contained in this electronic mail
> >>>> message is intended only for the use of the designated
> >>>> recipient(s) named above. If the reader of this message is not
> >>>> the intended recipient, you are hereby notified that you have
> >>>> received this message in error and that any review,
> >>>> dissemination, distribution, or copying of this message is
> >>>> strictly prohibited. If you have received this communication in
> >>>> error, please notify the sender by telephone or e-mail (as
> >>>> shown above) immediately and destroy any and all copies of this
> >>>> message in your possession (whether hard copies or
> >>>> electronically stored copies).
> >>>> 
> >>> 
> >> 
> >> -- To unsubscribe from this list: send the line "unsubscribe
> >> ceph-devel" in the body of a message to majordomo@vger.kernel.org
> >> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >> 
> > 
> 
> 

-- 
-- 
Matt Benjamin
Red Hat, Inc.
315 West Huron Street, Suite 140A
Ann Arbor, Michigan 48103

http://www.redhat.com/en/technologies/storage

tel.  734-707-0660
fax.  734-769-8938
cel.  734-216-5309
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html