Agree, we're all trying to avoid that. Matt ----- Original Message ----- > From: "Willem Jan Withagen" <wjw@xxxxxxxxxxx> > To: "Matt Benjamin" <mbenjamin@xxxxxxxxxx> > Cc: "Allen Samuels" <Allen.Samuels@xxxxxxxxxxx>, "Casey Bodley" <cbodley@xxxxxxxxxx>, "Sage Weil" <sweil@xxxxxxxxxx>, > ceph-devel@xxxxxxxxxxxxxxx > 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@xxxxxxxxxxx> To: "Matt Benjamin" > >> <mbenjamin@xxxxxxxxxx>, "Allen Samuels" > >> <Allen.Samuels@xxxxxxxxxxx> Cc: "Casey Bodley" > >> <cbodley@xxxxxxxxxx>, "Sage Weil" <sweil@xxxxxxxxxx>, > >> ceph-devel@xxxxxxxxxxxxxxx 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@xxxxxxxxxxx> To: "Casey > >>>> Bodley" <cbodley@xxxxxxxxxx>, "Matt Benjamin" > >>>> <mbenjamin@xxxxxxxxxx> Cc: "Sage Weil" <sweil@xxxxxxxxxx>, > >>>> ceph-devel@xxxxxxxxxxxxxxx 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@xxxxxxxxxxx > >>>> > >>>> > >>>> -----Original Message----- From: Casey Bodley > >>>> [mailto:cbodley@xxxxxxxxxx] Sent: Wednesday, February 03, 2016 > >>>> 1:26 PM To: Matt Benjamin <mbenjamin@xxxxxxxxxx> Cc: Sage Weil > >>>> <sweil@xxxxxxxxxx>; Allen Samuels <Allen.Samuels@xxxxxxxxxxx>; > >>>> ceph-devel@xxxxxxxxxxxxxxx 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@xxxxxxxxxx> To: "Allen Samuels" > >>>>>> <Allen.Samuels@xxxxxxxxxxx> Cc: ceph-devel@xxxxxxxxxxxxxxx, > >>>>>> mbenjami@xxxxxxxxxx, cbodley@xxxxxxxxxx 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@xxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxx > >> 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
