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 ��.n��������+%������w��{.n����z��u���ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
