On 10-10-2017 17:35, kefu chai wrote:
> On Tue, Oct 10, 2017 at 11:27 PM, Willem Jan Withagen <wjw@xxxxxxxxxxx> wrote:
>> On 10-10-2017 17:19, kefu chai wrote:
>>> On Tue, Oct 10, 2017 at 11:13 PM, Willem Jan Withagen <wjw@xxxxxxxxxxx> wrote:
>>>> On 10-10-2017 16:58, kefu chai wrote:
>>>>> On Tue, Oct 10, 2017 at 9:54 PM, Willem Jan Withagen <wjw@xxxxxxxxxxx> wrote:
>>>>>> On 10-10-2017 15:31, kefu chai wrote:
>>>>>>> On Tue, Oct 10, 2017 at 8:06 PM, Willem Jan Withagen <wjw@xxxxxxxxxxx> wrote:
>>>>>>>> On 10-10-2017 13:14, kefu chai wrote:
>>>>>>>>> + ceph-devel
>>>>>>>>>
>>>>>>>>> On Tue, Oct 10, 2017 at 4:49 AM, Willem Jan Withagen <wjw@xxxxxxxxxxx> wrote:
>>>>>>>>>> Hi Kefu,
>>>>>>>>>>
>>>>>>>>>> Sort of wondering what in the current code below is the relation between
>>>>>>>>>> gpertools and tcmalloc?
>>>>>>>>>
>>>>>>>>> could you be more specific?
>>>>>>>>
>>>>>>>> While looking at the code of CMakeLists.txt:286, in the case that no
>>>>>>>> ALLOCATOR is defined.
>>>>>>>> There the current flow of code seems to suggest that gperf-tools is
>>>>>>>> always linked to tcmalloc. And once gperftools is found, the ALLOCATOR
>>>>>>>> is set to tcmalloc. This then breaks rocksdb building.
>>>>>>>> `set(HAVE_LIBTCMALLOC ${GPERFTOOLS_FOUND})`
>>>>>>>> like:
>>>>>>>> ```
>>>>>>>> CMake Error at cmake/modules/BuildRocksDB.cmake:63 (message):
>>>>>>>> Incompatible tcmalloc v2.6.1 and rocksdb v5.8.0, please install
>>>>>>>> gperf-tools
>>>>>>>> 2.5 (not 2.5.93) or >= 2.6.2, or switch to another allocator using
>>>>>>>> 'cmake -DALLOCATOR=libc'.
>>>>>>>> Call Stack (most recent call first):
>>>>>>>> src/CMakeLists.txt:825 (build_rocksdb)
>>>>>>>> ```
>>>>>>>>
>>>>>>>>>> Reason for the question is that once the gperf packages is installed,
>>>>>>>>>> as a bonus the code below declares the allocator to be tcmalloc.
>>>>>>>>>> But gperf under FreeBSD does not have tcmalloc.
>>>>>>>>>
>>>>>>>>> please note gperf here is not GNU perf [1] but google-perftools. and
>>>>>>>>> why do you claim the gperf under FreeBSD does not have tcmalloc? could
>>>>>>>>> you elaborate this a little bit?
>>>>>>>>
>>>>>>>> My bad, I mixed gperf and gperf-tools. We are talking about gperf-tools.
>>>>>>>> And yes, gperftools brings tcmalloc but not in the version mix that is
>>>>>>>> asked for. gperf-tools was at 2.5 one time, but has upgraded to 2.6.1_1
>>>>>>>> on FreeBSD[1]. Getting other versions will require manual work to get it
>>>>>>>> to work.
>>>>>>>>
>>>>>>>> But the question is:
>>>>>>>> Do I really want my allocator to be tcmalloc when the native
>>>>>>>> libc allocator is jemalloc?
>>>>>>>
>>>>>>> i think it's up to you.
>>>>>>
>>>>>> Oke, it is what the code now forces...
>>>>>> And I've tried avoiding tcmalloc uptil now, and would like to do so for
>>>>>> the time being..
>>>>>>
>>>>>>>> So is the test in CMakeLists.txt:286-324 what we want on FreeBSD?
>>>>>>>
>>>>>>> see http://tracker.ceph.com/issues/21422. so again, it's up to you.
>>>>>>
>>>>>> The tracker suggests that it is an error in 2.5.93, but
>>>>>> cmake/modules/BuildRocksDB.cmake suggests that it is only fixed in
>>>>>> 2.6.2...??
>>>>>
>>>>> 2.6.2 is not yet released. so if you want to stick with tcmalloc, you
>>>>> need to build from the latest (or recent enough) source. actually, i
>>>>> am not sure what you question is..
>>>>
>>>> The question: Do you know if 2.6.2 is the first gperf-tools-version >
>>>> 2.5.93 where this bug from the tracker is solved?
>>>
>>> https://github.com/ceph/ceph/pull/17788/commits/ff8d6a730bb774271b9eea6af338e2d3ce3c48a5
>>
>> fascinating reading...
>> Shows that managing version can be a bitch.
>>
>>>>>>>> The workaround this (for the time being) is to call cmake with
>>>>>>>> -DALLOCATOR=libc as is suggested.
>>>>>>
>>>>>> I'll use this as workaround for the time being, since that is least
>>>>>> invasive. And when that works out, try and make a PR for the allocator
>>>>>> selector in CmakeLists.txt, and/or wait until gperf-tools 2.6.2 is
>>>>>> available on FreeBSD.
>>>>>
>>>>> what is issue you want to address?
>>>>
>>>> The issue I want to address is that I'm not able to build the intree
>>>> rocksdb ATM. Because tcmalloc is not => 2.6.2, and tcmalloc is required
>>>> because gperf-tools is detected.
>>>
>>> the error message offered two solutions. i think, what you need is
>>> just to choose one of them.
>>
>> Right, so I'm going with libc for the moment...
>>
>> Thanx for your patient explanations,
>
> i did send a mail with title of 'fix for "crash in rocksdb LRUCache
> destructor with tcmalloc"' to this mailing list. if you have had read
> it, it'd save both of us some time.
I was/am about a zillion mails behind on Ceph-lists due to too much work
at my paying dayjob. And then still I might have forgotten about it
because it speaks about fc25/26 and tcmalloc. Where I only just today
found out that gperf-tools does use tcmalloc.
So I'm sorry for your time, but for me I feel a bit more educated.
--WjW
--
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
