baotonglu / dash Goto Github PK

Hi, I learnt your dash-ex hash tables and have two questions.

1. Why the number of stash bucket is 2, which is different from the description in your paper.

2. Run time seems strange.

I did not change the parameters in your run.sh, where the warm-up workload is 10M, and benckmark workload is 190M.

In initial several experiments, dash runs pretty slow with the same shell script. But later, it seems that dash-ex is stuck after loading warm-up 5M data.

I feel confused because I have already run dash-ex about 6 times, where dash-ex works pretty well. I try to rebuild the project, but it is still stuck in loading warm-up phase.

The following is my DCPMM's states.

Could you give me some suggestions about how to figure out the reason? Looking forward to your reply, thanks!

code such as:key_hash = h(curr_key->key, curr_key->length);
So how the function h works?I can't find any definition of it.I'll be very appreciated if u can answer my question!

FrankLin

I pulled down the code of Dash from github and change the workload with the one we generated ourselves, I ran into a segment fault when I run concurr_search after inserting 50 million data, and when I located it with gdb, I found that it happened in this line：
SSE_CMP8(*curr_FingerArray, meta_hash);、
Do you know what caused this problem?
Thanks！

In allocator.h there is an #include <garbage_list.h>. However, there is no garbage_list.h in the repository, so it does not build. Is this some external dependency or is it simply missing in the repository?

It seems that the new flag requires glibc 2.29 or newer. On my Ubuntu 18.04 system I upgraded linux kernel to 5.4 but the custom PMDK still wouldn't compile because glibc was 2.27. Once I upgraded my system to 20.04 (which also installed glibc 2.31), I could build it successfully.
Might be helpful to add this to the README.

In the definition of Table, a member char dummy[48]; exists(ex_finger.h:867), and I wonder the effect of it.
Is it for the alignment of something else?
Thanks.

In ex_finger.h:896

if (reinterpret_cast<Table<T> *>(reinterpret_cast<uint64_t>(old_sa->_[x]) &
                                   tailMask) != this) {
    neighbor->release_lock();
    target->release_lock();
    return -2;
  }

This code, in my opinion, is to check whether the key belongs to this table. But I don't know why tailMask is needed here.

static const char* layout_name = "hashtable";
pm_pool_ = pmemobj_create_addr(pool_name, layout_name, pool_size,CREATE_MODE_RW, (void*)pool_addr);

I tried to run the "test_pmem" and "example". However,both of them got an error called "failed to create a pool;". I think the reason is that the layout_name might be incomplete. Should I finish the layout_name by myself?

Hi, Dash is a great algorithm and a great piece of engineering.

I think it has applications beyond the persistent memory domain.
Few questions.

1. What's the origin of the name "dash" ? What does it mean?
2. Seems that many design choices are applicable for a main memory hash table as well. Did you try comparing dash table to other state-of-the-art implementations?

Hi, I have a small problem after reading Dash, that is, how do you deal with the insertion request in the process of rehashing, do you lock the entire segment? I did not find a specific description in the paper.
Thanks!

In ex_finger.h line 1948 to 1972

    old_sa = dir;
    dir_entry = old_sa->_;
    x = (key_hash >> (8 * sizeof(key_hash) - old_sa->global_depth));
    if (target->local_depth < old_sa->global_depth) {
      if (Test_Directory_Lock_Set()) {
        goto REINSERT;
      } // Thread 1 here hangs up
      ADD(&old_sa->counter, 1);
      Directory_Update(old_sa, x, new_b, target);
      SUB(&old_sa->counter, 1);
      /*after the update, need to recheck*/
      if (Test_Directory_Lock_Set() || old_sa->version != dir->version) {
        goto REINSERT;
      }
    } else {
      Lock_Directory();
      if (old_sa->version != dir->version) {
        Unlock_Directory();
        goto REINSERT;
      }
      while (old_sa->counter != 0) // thread 2 passes this before the counter increment
        ;
      Directory_Doubling(x, new_b, target); // now thread 1 in Directory_Update and thread 2 in Directory_Doubling
      Unlock_Directory();
    }

I think the counter of dir is something like a RWLock, but it may not run as expected.
Consider a situation:
Thread 1 Test_Directory_Lock_Set pass but hang up before ADD(&old_sa->counter, 1);
Thread 2 Lock_Directory and test old_sa->counter is zero, so it begins Directory_Doubling.
Then thread 1 and thread 2 may operate together on the dir.

I think the fingerprints should be persisted as your paper says, but I can't find the corresponding code in ex_finger.h(line 369).