Ceph

• hammer backport https://github.com/ceph/ceph/pull/4507

In fact, b2781fb5638afae7438b983a912ede126a8c5b85 fix compilation, but the resulting binaries are not 100% working on armhf

ceph-osd & ceph-mon are working, but ceph & rbd commands are freezing.

Here is an IRC log with haomaiwan

----- SNIP -----

<dupont-y> Hi, Are you're the author of cycles.cc ?
<haomaiwa_> yeah
<dupont-y> I have some questions
I'm working on armhf architecture
And AFAICS there is no arm equivalent to the special X86 instructions you use
RDSTC if I remember well
<haomaiwa_> Hmm
<dupont-y> 2 consequences : 1) Hammer wasn't compiling on armhf
(see http://tracker.ceph.com/issues/11432)
2) the fix I asked loic to incorporate is just fixing compilation, ceph-osd and ceph-mon are working fine, but ceph commands (and rbd commands) are not work,ing anymore
so my question :
is something like this is ok ?
#else
#warning No high-precision counter available for your OS/arch. Using a generic / slower workaround.
timespec ts;
clock_gettime(CLOCK_MONOTONIC, &ts);
return ts.tv_sec * (uint64_t)1000000000L + ts.tv_nsec;;

<haomaiwa_> hmm, I think it's ok to falldown for this
could you give a look at http://gperftools.googlecode.com/svn/trunk/src/base/cycleclock.h
<dupont-y> with this patch, ceph & rbd commands are now working ok, but I understand we're not exactly on par
yes
hum yes, I saw this code
<haomaiwa_> do you think it's possible to migrate to ceph?
<dupont-y> 2 problems here : 1) It's not working on all arm platforms, only recent ones
2) AFAICS, you have to specially initialise "unlock" each core of cpu for that
Beware I'm not an ARM specialist, just an user :)
<haomaiwa_> ok, maybe we could ask for more users involve into this question. Because we want to make cycles spread for more ceph codes
so maybe cycles will become a frequent function
<dupont-y> good to know
I'll try to dig a proper fix for arm
<haomaiwa_> yeah, if you are urgent, you can just falldown to use clock_gettime instead
<dupont-y> but in the meantime, are you ok for the generic fix ? It's better than issuing an #error
ok
BTW what is the problem with a "generic fix" : lack of precision ? Too much time in syscalls ?
<haomaiwa_> both
<dupont-y> ok :)
<haomaiwa_> cycles will be used in performance counter collect
<dupont-y> ok, so you need precision & speed
<haomaiwa_> :-)
<dupont-y> I'll try to implement a proper fix for arm, but I need to experiment, it seems not an easy task on arm - there is lots of posts on the subject.
<haomaiwa_> thanks!
<dupont-y> Have a nice day !