ok, thanks. I will update my PR 17661 only keep the step 5. src/common/buffer.cc _len += bl._len; if (!(flags & CLAIM_ALLOW_NONSHAREABLE)) bl.make_shareable(); _buffers.splice(_buffers.begin(), bl._buffers ); bl._len = 0; bl.last_p = bl.begin(); + + // 5. update the last_p point to the lasted ptr + last_p = begin(); 2017-09-18 16:05 GMT+08:00 Piotr Dałek <piotr.dalek@xxxxxxxxxxxx>: > On 17-09-18 09:47 AM, 关云飞 wrote: >> >> hello kefu chai, >> >> These two days I carefully considered the pr 17661 and looked the code >> about bufferlist and I still think the steps of 1-3 is needed. >> Although the ptr::_off can guarantee bufferlist to be >> copied/read/decode/write_file rightly, this will lead a bufferlist not >> clean and >> will waste memory like the picture in annex. >> >> Of course, it's also possible that i am not thinking about it, do you >> have any suggestions? > > > In your diagram, you show the case where allocated memory blocks are > underutilized, wasting memory. If I understand you (and code from your PR) > correctly, you want to move data from the middle of allocated blocks to > front of them to reclaim memory - but the way you propose isn't any good > really, you allocate new block of memory (and accompanying bufferptr), copy > data from existing block to newly allocated one, then destroy old - this is > very expensive CPU-wise, way more expensive than leaving these bytes wasted. > Most of the time it wouldn't matter anyway, as most of bufferlists have > limited lifetime and would get destroyed soon. > > -- > Piotr Dałek > piotr.dalek@xxxxxxxxxxxx > https://www.ovh.com/us/ > -- > 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
