>>the code logic would touch crc cache is bufferlist::crc32c and invalidate_crc. Also for pg_log::_write_log(), but seems it is always miss and use at once, no need to cache crc actually? So we may need to add some option to enable or disable it, or some identifier to instruct bufferlist wheher crc should be cached when initiating a new bufferlist. I think it may still be useful on the platform without hardware crc acceleration or large chunks writing (as it may relate to the length of buffer::ptr). So we can bypass the small buffer::ptr without crc cache Or also don't cache the things like pg_info, attrs as they are always not reused in FileJournal writing? Regards Ning Yao 2015-11-11 16:25 GMT+08:00 Evgeniy Firsov <Evgeniy.Firsov@xxxxxxxxxxx>: > Rb-tree construction, insertion, which needs memory allocation, mutex > lock, unlock is more CPU expensive then streamlined crc calculation of > sometimes 100 bytes or less. > > On 11/11/15, 12:03 AM, "池信泽" <xmdxcxz@xxxxxxxxx> wrote: > >>Ah, I confuse that why the crc cache logic would exhaust so much cpu. >> >>2015-11-11 15:27 GMT+08:00 Evgeniy Firsov <Evgeniy.Firsov@xxxxxxxxxxx>: >>> Hello, Guys! >>> >>> While running CPU bound 4k block workload, I found that disabling crc >>> cache in the buffer::raw gives around 7% performance improvement. >>> >>> If there is no strong use case which benefit from that cache, we would >>> remove it entirely, otherwise conditionally enable it based on the >>>object >>> size. >>> >>> ‹ >>> Evgeniy >>> >>> -- >>> 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 >> >> >> >>-- >>Regards, >>xinze > -- 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
