On Wed, 21 Dec 2016, Igor Fedotov wrote:
> On 12/20/2016 11:15 PM, Sage Weil wrote:
> > It seems like we have a few common cases...
> >
> > 1) big blob, single ref (e.g., immutable large object, and then the entire
> > thing is referenced, modulo the last block).
> >
> > 2) tiny blob, single alloc unit. a counter is sufficient.
> >
> > 3) everything else in between...
> >
> > We could probably get away with special-case efficient representations of
> > just 1 and 2?
> I'd say 1) = entire blob is referenced just once. And 2) = single alloc unit
> and partially referenced.
>
> Then we need at minimum a bit flag for 1), 'int' for 2) and vector<int> for
> 3).
>
> Possible implementations are
> A.{
> int standalone_counter; //this covers 1 & 2, value greater than alloc unit
> means 1)
> vector<int> per_au_counters; // and this one for 3 with the first counter
> stored in standalone_counter
> }
> vs.
> B.{
> //reuse some blob flag for 1)
> vector<int> per_au_counters; //for 2) and 3)
> }
> vs.
> C.{
> vector<int> per_au_counters; //for all cases
> }
>
> A. Saves one allocation for 1 & 2, wastes 4 bytes for 1. Plus requires some
> simple tricks to use both standalone counter and vector.
> B. Saves 1 allocation and 4 bytes for 1. Unified counter vector processing but
> some minor tricks with a flag.
> C. Needs +1 allocation for 1 & 2. And wastes 4 bytes for 1. Unified counter
> processing
>
> I'd rather prefer B. implementation.
vector<int> is 24 bytes. So if we're worried about memory, I think we
want to have an alternative strategy. Something like:
uint8_t au_order; ///< size of allocation unit (min_alloc_size may change)
union {
long *ref_by_au; ///< dynamically allocated array of bytes per au
long ref_in_single_au; ///< refs if blob is a single au (au_order=0?)
}
Something simple like that?
I suspect get_ref/put_ref will get quite a bit simpler and more efficient
with per-au buckets.
Also, for compressed blobs, we can use the ref_in_single_au mode since we
can't deallocate it piecewise anyway...
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
