On Wed, Apr 25, 2018 at 12:59 AM, Adam C. Emerson <aemerson@xxxxxxxxxx> wrote:
> On 25/04/2018, kefu chai wrote:
> [snip]
>>
>> no. see
>> === 8< ====
>> template <typename... Args>
>> void log(log_level level, const char* fmt, Args&&... args) {
>> if (is_enabled(level)) {
>> try {
>> do_log(level, fmt, std::forward<Args>(args)...);
>> } catch (...) {
>> failed_to_log(std::current_exception());
>> }
>> }
>> }
>> === >8 ===
>
> I have thought off and on and chatted with a few others about the
> using a binary log, since the runtime cost of all that stringification
> at high log levels is Not Insignificant.
yeah, i recall the discussion in a performance meeting the other day.
so are we going to have a dictionary for each log entry? and for each
log entry, it will contain <index, variable length blob>. we will ship a tool
which embeds a dictionary, in which we can lookup a log entry by its
index to find out <a fmt string, a list of indices into another dictionary>.
in "another" dictionary, it contains the recipes for printing various objects
in Ceph.
>
> If we required that only contiguous objects could be logged (or
> continguous subobjects. Maybe define an operator that gives returns an
> address/length pair.) it would also solve the evaluation problem
> handily. The only choice would be whether to dump or not. (That might
you mean dump the object? even it leads to memcpy and more disk I/O,
i think we need to bite the bullet. because the object being logged varies
over time.
> be too limiting, though we could probably get a good deal of mileage
> from it.)
>
> Even using encode/decode would probably be an improvement over
> straight-up stringification.
yeah, in addition to encode()/deocde()/print()/operator<<, we could have
another log() function for every struct/class, which need to be logged.
this function will prepare a pair of <index, list of address/length pair>, so
the underlying logger can dump the interesting bits to disk with the recipe
index to print these bits.
>
> We could possibly make a macro for logging that implicitly constructs
> a lambda that's only evaluated if the log level is high enough.
>
> --
> Senior Software Engineer Red Hat Storage, Ann Arbor, MI, US
> IRC: Aemerson@OFTC, Actinic@Freenode
> 0x80F7544B90EDBFB9 E707 86BA 0C1B 62CC 152C 7C12 80F7 544B 90ED BFB9
--
Regards
Kefu Chai
--
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
