On Sun, 10 Jun 2018, kefu chai wrote: > On Sun, Jun 10, 2018 at 3:16 AM Sage Weil <sage@xxxxxxxxxxxx> wrote: > > > > > > > When I went through the data structures, it generally seemed like > > > > > message-passing about data structure changes would be a better way to > > > > > go than trying to employ any kind of real RCU library (or even the > > > > > exact abstractions). We might maintain local pointers to constant > > > > > structures with a per-core ref count to protect deletion, but proper > > > > Is there already a per-core ref-counting foo_ptr<> that does this? (This > > being a core/thread-local refcount, and a global atomic refcount?) This > > i don't think we have a foo_ptr<> for this now. i will pull together > one. tracked by https://github.com/ceph/ceph/projects/2#card-10448235 > . > > > seems useful in lots of places (probably most places we use > > RefCountedObject now... things like OSDSession). > > OSDSession is only used by Objecter, which will be wrapped by a mini > service, so i guess we don't need to access it from seastar threads. > probably OpTracker is a better example? because messages are allocated > by the core where it is received, and the core actually *owns* it. so, > if we want to track the life cycle of a request, and allow user to > query them, for instance, to dump slow requests, we should have a > seastar mini service for this purpose, and the mini service is hosted > by a configured core, where it has a local refcount, when it decrement > to zero, it will send a message to the core where the message was > allocated to decrement the global refcount. Yeah, that's a good example. I was thinking of the OSD's session object, which I guess is just Session. Wouldn't a simple std::atomic<> work for the global refcount, though? That'll be less expensive in the (rare) case of adjusting the global refcount. (I guess it might slow progress on the shard, though, when the cacheline is bounced between cores.) 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
