On 12/13/2017 10:34 AM, Sage Weil wrote:
We had a great chat yesterday with Avi Kivity @ Scylla about seastar in
ceph, and were talking about where to start... One candidate was to carve
off the entire messenger and reimplement using seastar futures/promises.
Another thought that is somewhat trivial but probably necessary and
smallish is the log/ framework. This might be a good test case for the
legacy <-> seastar communications infrastructure. It's all one-way, which
simplifies things a bit, and the implementation should be pretty
straightforward?
I know we can't rely on the current debug stuff for
tracing/instrumentation, but I don't think teh need for a debug log is
going to go away.
Another question is how the logger/perfcounters will need to change in a
seastar world.
That's really exciting! Josh and Greg mentioned in standup that we
wouldn't use the seastar memory allocator at all. Would it be
difficult/counterproductive to carve out some memory that seastar could
manage itself while using tcmalloc or whatever for the posix side?
It seems to me like seastar's desire override new/delete isn't really a
good long term solution for anyone.
Regarding where to start:
I'd be really happy just to see seastar building properly in ceph and a
reactor up and running doing *anything*.
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
--
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
