Re: why we use two ObjectStore::Transaction in ReplicatedBackend::submit_transaction?

2015-11-01 Thread Sage Weil
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%

RE: why we use two ObjectStore::Transaction in ReplicatedBackend::submit_transaction?

2015-11-01 Thread Somnath Roy
Behalf Of Sage Weil Sent: Sunday, November 01, 2015 6:47 AM To: 池信泽 Cc: Ning Yao; ceph-devel@vger.kernel.org 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

RE: why we use two ObjectStore::Transaction in ReplicatedBackend::submit_transaction?

2015-11-01 Thread Somnath Roy
ber 01, 2015 8:59 AM To: Sage Weil; 池信泽 Cc: Ning Yao; ceph-devel@vger.kernel.org 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

Re: why we use two ObjectStore::Transaction in ReplicatedBackend::submit_transaction?

2015-10-31 Thread 池信泽
If we keep them separate and pass them to ObjectStore::queue_transactions() ,the cpu usage of ObjectStore::queue_transactions() would take up from 6.03% to 6.76% compared with re-using op_t items. 2015-11-01 11:05 GMT+08:00 池信泽 : > Yes, I think so. > keeping them separate and

Re: why we use two ObjectStore::Transaction in ReplicatedBackend::submit_transaction?

2015-10-31 Thread 池信泽
the op_t items are encoded in issue_op, so after issue_op, we could use it directly instead of local_t items? 2015-10-31 21:18 GMT+08:00 Sage Weil : > On Sat, 31 Oct 2015, ??? wrote: >> hi, all: >> >> There are two ObjectStore::Transaction in >>

RE: why we use two ObjectStore::Transaction in ReplicatedBackend::submit_transaction?

2015-10-31 Thread Somnath Roy
Weil Cc: 池信泽; ceph-devel@vger.kernel.org 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

Re: why we use two ObjectStore::Transaction in ReplicatedBackend::submit_transaction?

2015-10-31 Thread 池信泽
er 31, 2015 8:35 AM > To: Sage Weil > Cc: 池信泽; ceph-devel@vger.kernel.org > 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 se

Re: why we use two ObjectStore::Transaction in ReplicatedBackend::submit_transaction?

2015-10-31 Thread Sage Weil
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.

Re: why we use two ObjectStore::Transaction in ReplicatedBackend::submit_transaction?

2015-10-31 Thread Ning Yao
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