Apply MV-RLU on chainhash.hh

[MadPlayer]

MV-RLU를 chainhash.hh 에 적용하면서 생기는 문제들입니다.

Table of Contents

1. chainhash
   1. replace from
   2. seqlock
   3. How to apply MV-RLU on chainhash
      1. 현재 상태
      2. 문제
      3. 구현사항

chainhash

replace from

원래 RCU를 사용할 때는 Writer가 spinlock을 사용함으로 replace from 같은 엄청 긴 복잡한 코드를 실행하는 것이 문제 없을지 모르나 mvrlu는 꽤 힘들것으로 보임

seqlock

RCU와 seqlock을 결합하는 이유는 크게 두가지라고 생각함

1. linked list같은 데이터를 읽을 때 null pointer 참조 방지
2. 항상 최신의 consistent한 데이터를 읽어야 하는 경우 (no stale data)

How to apply MV-RLU on chainhash

현재 상태

MV-RLU를 system에 이식해서 benchmark 실행가능함

문제

• seqlock seqlock은 한번에 하나의 Writer만 허용

• MV-RLU로 관리되는 객체는 header가 필요한데 어떻게 범용적으로 관리할 것인가? 추천방향

  class rcu_freed;

  의 경우처럼 구현한다.

• benchmark 실행시 최종 node 개수가 다른 문제가 생김 [BUG]

• 객체 소멸자 문제 MV-RLU에서는 객체가 바로 소멸하지 않고 mvrlu.c 내부에서 적절한 시점에 제거되는데 이때 mvrlu.c는 C 코드이므로 객체의 소멸자를 호출할 방법이 없다. 추천방향

  call_rcu(obj_ptr, kfree);

  위의 함수는 소멸자 (kfree)를 객체의 포인터와 함께 관리하다가 적절한 시점에 소멸자를 이용해서 객체를 제거한다.

• 객체 복사 문제 MV-RLU에서는 객체를 memcpy를 이용해 log로 복사해서 사본을 만드는데 이는 객체에 포인터가 있는 경우 심각한 문제가 된다.

구현사항

• mvrlu_object 객체 구상
  • 객체의 헤더를 적절히 추가하는 것 (C 코드에서 읽어낼 수 있게)
• islist 단순한 linked-list인데 인터페이스를 그대로 유지하면서 MV-RLU 적용
• 만약 seqlock을 사용해야 한다면 다수의 Writer가 동시에 실행할 수 없다 -> seqlock 삭제

[MadPlayer]

객체에 pointer 가 있는 경우 혹은 pointer 객체 혹은 하나만 존재해야 하는 객체 (ex, spinlock)를 값으로 가지는 경우 MV-RLU로 동기화하는 것은 보류하고 값으로만 이루어진 경우를 chainhash에 적용하는 것으로 하였습니다.

값으로만 이루어진 경우는 다음의 조건을 만족합니다.

• 객체 내부에 pointer 맴버가 없다.
• 논리상 한 시점에 반드시 하나의 존재만 있어야 한다.

첫번째 조건을 만족하는 값을 사용하면 구현상 다음의 이점이 있습니다

• 생성자, 소멸자, 복사생성자 가 필요없다.

[MadPlayer]

위의 조건에 부합하는 값만으로 구성된 hash list에 mvrlu를 적용했습니다. 다만 특정 행위를 반복하면 inode<->mnode 간 mapping에 inconsistency가 생기는 문제가 있습니다. 정확한 요인을 분석해야 할 것으로 보입니다. https://github.com/MadPlayer/mvcc-os/tree/c9e2aa232bb847a639d3f85ce5e9a13646c121ef

다음의 방법을 이용하면 오류를 재생산할 수 있습니다. testrecovery -c 15 -o / rm -r testdir sync

혹은 많은 수의 파일을 만들고 그 폴더를 삭제한 뒤에 sync을 호출해도 같은 문제가 발생합니다. 경우에 따라서 block되는 경우도 생깁니다.

[MadPlayer]

기존에 scalefs에서 chainhash를 사용하기 전에 밖에서 rcu section (refcache section)을 여는 것을 확인했습니다. (scoped_gc_epoch) https://github.com/bigsys-gnu/mvcc-os/blob/0be3b1ec7a545921670274c33177adf75ac7bcc1/os/sv6/scalefs/kernel/scalefs.cc#L122-L130

get_inode 함수안에는 이렇게 chainhash로 lookup을 합니다. https://github.com/bigsys-gnu/mvcc-os/blob/0be3b1ec7a545921670274c33177adf75ac7bcc1/os/sv6/scalefs/kernel/scalefs.cc#L96-L106

그리고 chainhash lookup에서는 이렇게 또 rcu section (refcache section)을 엽니다. (scoped_gc_epoch) https://github.com/bigsys-gnu/mvcc-os/blob/0be3b1ec7a545921670274c33177adf75ac7bcc1/os/sv6/scalefs/include/chainhash.hh#L302-L314

왜 이러한 기능을 사용한 것인지 파악해야 할것 같습니다. @kjhnet @gitrvy2

[bigsys-gnu]

nested lock을 시도하는게 아닌지 모르겠네요. "rcu section (refcache section)" 이 부분이 무슨 말인지?

[MadPlayer]

nested lock을 시도하는게 아닌지 모르겠네요. "rcu section (refcache section)" 이 부분이 무슨 말인지?

sref에서 요구하는 것이 포인터의 클레스가 referenced라는 클레스를 상속받기를 요구하는데요 실제 refcache를 사용하기 위한 클레스의 이름과 동일해서 착각했습니다.