On Wed, 4 Nov 2015, ??? wrote:
> hi, all:
>
> I am focus on the cpu usage of ceph now. I find the struct (such
> as pg_info_t , transaction and so on) encode and decode exhaust too
> much cpu resource.
>
> For now, we should encode every member variable one by one which
> calling encode_raw finally. When there are many members, we should
> encode it many times. But I think, we could reduce some in some cases.
>
> For example , struct A { int a; int b; int c }; ceph would
> encoding int a , and then encode int b , finally int c. But for this
> case , we could calling bufferlist.append((char *)(&a), sizeof(A))
> because there are not padding bytes in this struct.
>
> I use the above optimization, the cpu usage of object_stat_sum_t
> encoding decrease from 0.5% to 0% (I could not see any using perf
> tools).
>
> This is only a case, so I think we could do similar optimization
> other struct. I think we should pay attention to the padding in
> struct.
We have to be careful because we need to ensure that the encoding
is little-endian. I think teh way to do this is to define a struct like
struct foo_t {
__le64 a;
__le64 b;
__le64 c;
...
};
and just make a foo_t *p that points into the buffer. There were some
patches that did this that came out of the Portland ahckathon, but I'm not
sure where they are... Josh, do you remember?
FWIW I think pg_stat_t (and friends) is a good first start since it is
expensive and part of the MOSDOp and MOSDRepOp.
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
