On Tue, 24 Apr 2018, kefu chai wrote:
for taking the full advantage of seastar, i don't think we should continue using the existing logging infrastructure, as it uses a grand lock for protecting the log entry queue. and hence is not lock free, and the logging thread will be competing with the seastar's reactor thread.
As I'm sure folks here are too familar with, logging is a "black art", especially with respect to performance. :-| It might be a good opportunity to consider not just what but how often we log text messages. Every bit of server-side software has to deal with this at some point, it seems. If this is the natural way to do it in Seastar, maybe it's best not to fight it?
Besides the performance considerations you mentioned, is the key tradeoff that we would loose the (honestly, to me a bit mysterious-- Joao just explained them to me the other day!) magic log level numbers? Is 5 enough granularity? In other words, how often are the really fine-grained features (ie. "dout(6)") actually used?
i think a compromised approach would be using a compile-time switch to define two implementations for "dout(lv)" for the code shared by osd and non-seastarized parts of ceph. and we can use the same facility (stdout or syslog) and the same prefix as seastar does in our seastar implementation, so it would be easier to debug osd-in-seastar in future.
This is not meant as a criticism of the "good things" dout() does for us, but I have to take the opportunity point out that I've *just* been having recent inconvience using it becuase of dout()'s macro-ness. Nothing too serious, but because names are expanded in the macro is causing some extra hoops. I guess I'm asking if we want to add complexity to a macro?
That's my two bits, anyway! -Jesse -- 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
