Huh..It seems the op_t is already copied in generate_subop() -> ::encode(*op_t, wr->get_data());...So, this shouldn't be an issue.. -----Original Message----- From: ceph-devel-owner@xxxxxxxxxxxxxxx [mailto:ceph-devel-owner@xxxxxxxxxxxxxxx] On Behalf Of Somnath Roy Sent: Sunday, November 01, 2015 8:59 AM To: Sage Weil; 池信泽 Cc: Ning Yao; ceph-devel@xxxxxxxxxxxxxxx Subject: RE: why we use two ObjectStore::Transaction in ReplicatedBackend::submit_transaction? Sage, Is it possible that we can't reuse the op_t because it could be still there in the messenger queue before calling parent->log_operation() ? Thanks & Regards Somnath -----Original Message----- From: ceph-devel-owner@xxxxxxxxxxxxxxx [mailto:ceph-devel-owner@xxxxxxxxxxxxxxx] On Behalf Of Sage Weil Sent: Sunday, November 01, 2015 6:47 AM To: 池信泽 Cc: Ning Yao; ceph-devel@xxxxxxxxxxxxxxx Subject: Re: why we use two ObjectStore::Transaction in ReplicatedBackend::submit_transaction? On Sun, 1 Nov 2015, Sage Weil wrote: > On Sun, 1 Nov 2015, ??? wrote: > > Yes, I think so. > > keeping them separate and pass them to > > ObjectStore::queue_transactions() would increase the time on > > transaction encode process and exhaust more cpu. > > > > The transaction::append holds 0.8% cpu on my environment. > > The transaction encoding is also really a bottleneck which process > > holds 1.8% cpu on my environment. > > Where is the append() caller you're looking at? I'm not seeing it. Oh, I see: https://github.com/ceph/ceph/pull/6439 This makes sense to me. 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 ㈤旃??迆??瑬+-遍荻w疄藳笔鈓??^介b炟^n噐■?侂h櫒璀?Ⅷ 瓽珴閔?(殠娸"濟?m?飦赇z罐枈帼f＂穐殘坢 ��.n��������+%������w��{.n����z��u���ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
