Hi Radek,
Thanks for joining this topic, I am not very clear about the problem you solving now. Could you please describe in detail, why there is cache ping-pongs (TLS), how will you solve it?
Thanks!
-Chunmei
> -----Original Message-----
> From: Radoslaw Zarzynski [mailto:rzarzyns@xxxxxxxxxx]
> Sent: Tuesday, August 14, 2018 4:39 AM
> To: Liu, Chunmei <chunmei.liu@xxxxxxxxx>
> Cc: Kefu Chai <kchai@xxxxxxxxxx>; The Esoteric Order of the Squid Cybernetic
> <ceph-devel@xxxxxxxxxxxxxxx>
> Subject: Re: ceph seastar perfcounters implementation
>
> Hello!
>
> I'm working on an implementation [1] of perf counters that tries to avoid cache
> ping-pongs (TLS) and move as much as possible to compile-time while keeping
> the current logic.
>
> The idea behind is to have the possibility of coexistence with PerfCounters/
> PerfCountersCollection and migrate gradually. Although not directly targeting
> SeaStar, I believe similar problems might pop-up also there:
>
> * number of threads is not exactly known at compile time,
> * number of counter's instances is variable and depends on run-time events.
>
> Regards,
> Radek
>
> [1] https://github.com/ceph/ceph/compare/master...rzarzynski:wip-common-
> perfctr-tls
>
> On Sat, Aug 11, 2018 at 1:09 AM, Liu, Chunmei <chunmei.liu@xxxxxxxxx> wrote:
> > Hi kefu,
> >
> > I took a look on perfcounters implementations in Ceph, and found in
> Messenger each worker threads has its own perfcounters instance, and in
> bluestore, it is single thread in each part, and only one perfcounter instance, in
> OSD also no perfcoutners instance shared across threads.
> >
> > So in Ceph Seastar mode, how about each seastar thread has its own
> perfcounters? That means no need consider the perfcounters shared between
> threads?
> >
> > What is your idea?
> >
> > Thanks!
> > -Chunmei
> >
