Segmentation fault on YCSB with CLHT, after using libvmmalloc about recipe HOT 9 CLOSED

It looks segmentation fault occurs while starting GC by memory manager used in CLHT. Could you comment out the line where memory manager releases memory allocated for prior hash table and then run your experiments again?

$ vi P-CLHT/src/clht_lb_res.c

Find the code line number 806 and comment out that line.

from recipe.

This works. Would it lead to memory leakage?

from recipe.

There would be memory leakage issue as we disabled epoch memory manager. I think that the problem happens while linking the memory manager library of CLHT (ssmem) with libvmmalloc. Let me try to solve this issue later.

from recipe.

Hi Yige,

I have updated some implementations in benchmark source codes for P-CLHT (last commit). After this updates, P-CLHT looks working correctly with libvmmalloc without segmentation faults at least on my machine.

The segmentation faults happen because gc procedures caused by rehashing started earlier than every thread finishes the initialization of gc threads.

I solved this problem by adding some barriers making threads wait until every thread finishes the initialization of garbage collector.

Could you do git pull once and then test it on your machine again? If you still confirm segmentation faults, please let me know.

Thanks,
Sekwon

from recipe.

Hi Sekwon,

The patch resolves the segfault, so I'm closing the issue.

It seems the clht_gc_release (garbage collector?) is consuming much running time. The throughput drops from ~94.24 ops/us to ~76.79 ops/us on my machine, from before the patch (with clht_gc_release commented out) to after the patch.

Thanks,
Yige

from recipe.

Hi Yige,

As you confirmed, gc procedures can influence the performance of CLHT. But, we also need to consider that CCEH has no epoch memory manager for reclaiming old hash table and it results in memory leaks while CLHT handles it.

Thanks,
Sekwon

from recipe.

Hi Sekwon,

I tried running YCSB workloada with recordcount=operationcount=10000000 and getting another segfault on gc. It's tested on DRAM, with not LD_PRELOAD for emulated pmem.

RECIPE$ ./build/ycsb clht a randint uniform 1
clht, workloada, randint, uniform, threads 1
Loaded 10000001 keys
Throughput: load, 17.891783 ,ops/us
Segmentation fault (core dumped)

RECIPE$ gdb build/ycsb core
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x000055a387bba486 in ssmem_release ()
[Current thread is 1 (Thread 0x7f31e2fff700 (LWP 1702))]
(gdb) bt
#0  0x000055a387bba486 in ssmem_release ()
#1  0x000055a387bb994e in clht_gc_release ()
#2  0x000055a387bb8e00 in ht_resize_pes ()
#3  0x000055a387bb873c in ht_status ()
#4  0x000055a387bb8b3e in clht_put ()
#5  0x000055a387b5380d in std::thread::_State_impl<std::thread::_Invoker<std::tuple<ycsb_load_run_randint(int, int, int, int, int, std::vector<unsigned long, std::allocator<unsigned long> >&, std::vector<unsigned long, std::allocator<unsigned long> >&, std::vector<int, std::allocator<int> >&, std::vector<int, std::allocator<int> >&)::{lambda()#10}> > >::_M_run() ()
#6  0x00007f32412d966f in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#7  0x00007f32415ac6db in start_thread (arg=0x7f31e2fff700) at pthread_create.c:463
#8  0x00007f324099688f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

from recipe.

Yige,

Sorry for confusion.

I missed to add gc initialization at run phase.

I have updated it through recent commit.

Could you do git pull once and then check it again?

from recipe.

Hi SeKwon,

This has been fixed by the latest commit so I'm closing the issue.

F.Y.I. I also noticed an increase in the throughput variance.

Thanks,
Yige

from recipe.