On Thu, 3 Dec 2015, Casey Bodley wrote: > > Well, yeah we are, it's just the actual Transaction structure which > > wouldn't be dynamic -- the buffers and many other fields would still > > hit the allocator. > > -Sam > > Sure. I was looking specifically at the tradeoffs between allocating > and moving the Transaction object itself. > > As it currently stands, the caller of ObjectStore can choose whether to > allocate its Transactions on the heap, embed them in other objects, or > put them on the stack for use with apply_transactions(). Switching to an > interface built around unique_ptr forces all callers to use the heap. I'm > advocating for an interface that doesn't. That leaves us with either std::move or.. the raw Transaction* we have now. Right? > > > It's true that the move ctor has to do work. I counted 18 fields, half of > > > which are integers, and the rest have move ctors themselves. But the cpu > > > is good at integers. The win here is that you're not hitting the allocator > > > in the fast path. To be fair, many of these are also legacy that we can remove... possibly even now. IIRC the only exposure to legacy encoded transactions (that use the tbl hackery) are journal items from an upgrade pre-hammer OSD that aren't flushed on upgrade. We should have made the osd flush the journal before recording the 0_94_4 ondisk feature. We could add another one to enforce that and rip all that code out now instead of waiting until after jewel... that would be satisfying (and I think an ondisk ceph-osd feature is enough here, then document that users should upgrade to hammer 0.94.6 or infernalis 9.2.1 before moving to jewel). sage -- 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
