Yeh, But using two transaction, I think it would malloc more memory and exhaust cpu in encode process. Because it would not reuse the append_buffer in bufferlist. I would give out the performance data after. 2015-10-31 23:58 GMT+08:00 Somnath Roy <Somnath.Roy@xxxxxxxxxxx>: > BTW, latest code base is already separating out 2 transaction. No more append call.. > > Thanks & Regards > Somnath > > -----Original Message----- > From: ceph-devel-owner@xxxxxxxxxxxxxxx [mailto:ceph-devel-owner@xxxxxxxxxxxxxxx] On Behalf Of Ning Yao > Sent: Saturday, October 31, 2015 8:35 AM > To: Sage Weil > Cc: 池信泽; ceph-devel@xxxxxxxxxxxxxxx > Subject: Re: why we use two ObjectStore::Transaction in ReplicatedBackend::submit_transaction? > > Yeah, since issue_op is called before log_operation, we may consider to reuse op_t after sent encoded op_t to the wire. local_t.append(), at least, does copy the op_bl in op_t transaction and we may avoid this memory copy, and if we can avoid this append operation as well as in sub_op_modify_impl(), it, at least, improves the performance 1%~2% under my testing environment using ssd as Filestore backend. > The only difference we find in this path is that local_t should be done first, but actually it seems that the order of the transaction is not quite important. If so, we may refactor and improve this? > Regards > Ning Yao > > > 2015-10-31 21:18 GMT+08:00 Sage Weil <sage@xxxxxxxxxxxx>: >> On Sat, 31 Oct 2015, ??? wrote: >>> hi, all: >>> >>> There are two ObjectStore::Transaction in >>> ReplicatedBackend::submit_transaction, one is op_t and the other one >>> is local_t. Is that something >>> critilal logic we should consider? >>> >>> If we could reuse variable op_t it would be great. Because it is >>> expensive to calling local_t.append(*op_t). >>> >>> There are similar logic in ReplicatedBackend::sub_op_modify_impl. >> >> The local_t items are only applied locally; the op_t items are encoded >> and sent over the wire to the replicas. >> >> If append() is expensive we should just refactor to avoid that. IIRC >> I got partway down this path but apparently didn't finish. The >> ObjectStore interface takes a list of transactions to apply, so I >> think it's just a matter of refactoring the interfaces a bit...? >> >> 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 -- 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
