Re: reducing buffer allocations

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Feb 5, 2016 at 6:33 AM, Sage Weil <sweil@xxxxxxxxxx> wrote:
> https://github.com/ceph/ceph/pull/5534
>
> does two things: (1) combine the buffer::raw reference count and buffer
> into a single allocation (ala make_shared), and (2) convert buffer::list
> into an intrusive_list, while embedding N (=3) buffer::ptr's in the
> buffer::raw so that most buffers require only 1 allocation (provided they
> aren't on more than N lists).
>
> This needs a rebase, and some benchmarking.  But before I pull it up, is
> this the right direction?  I saw little benefit from (2) after doing
> (1), but I was doing a really simple microbenchmark.  Do we want both, or
> just 1, or is there an alternative we should consider?

I think a another way is separating the owner of memory and the
reference to the part of memory. Like Buffer structure in
RAMCloud(https://github.com/PlatformLab/RAMCloud/blob/master/src/Buffer.h)

1. The Buffer(like bufferlist) own "vector<void*> allocations" to
store all associated memory to keep them. It will be convenient for
addition malloc(like getRange)
2. Chunk(like ptr) maintain *next ptr instead std::list

Hmm, it doesn't have much difference. FYI

>
> 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



[Index of Archives]     [CEPH Users]     [Ceph Large]     [Information on CEPH]     [Linux BTRFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux