Read-copy update (RCU) can provide ideal scalability for read-mostly workloads, but some believe that it provides only poor performance for updates. This belief is due to the lack of RCU-centric update synchronization mechanisms. RCU instead works with a range of update-side mechanisms, such as locking. In fact, many developers embrace simplicity by using global locking. Logging, hardware transactional memory, or fine-grained locking can provide better scalability, but each of these approaches has limitations, such as imposing overhead on readers or poor scalability on non-uniform memory access (NUMA) systems, mainly due to their lack of NUMA-aware design principles....

The last research paper I wrote before joining my current team, has been accepted to be presented by the EuroSys'20. The title of the paper is “An HTM-Based Update-side Synchronization for RCU on NUMA systems”.

지금 회사에 합류하기 전에 마지막으로 쓴 제 연구 논문이 EuroSys'20 에 액셉되었습니다. 논문의 제목은 “An HTM-Based Update-side Synchronization for RCU on NUMA systems” 입니다.

In some case, we need to send patches that made by other people instead. git send-email command can know this situation by itself by comparing the commit author information and mail sender’s information. In that case, git send-email automatically add From: line pointing the real author of the patch in the body of the mail so that maintainers applying the patches can set the author information correctly. For example, if “Alice alice@abc....

많은 개발 커뮤니티가 요즘은 Github 을 사용합니다만, 일부 커뮤니티는 여전히 메일링 리스트 기반 개발 스타일을 고수하고 있습니다. 리눅스 커널 커뮤니티가 좋은 예가 되겠죠. 이런 스타일에서는 모든 주요 커뮤니케이션이 이메일을 통해 이루어집니다. 패치는 메인테이너와 하나 이상의 공개 메일링 리스트를 향해 메일의 형태로 보내어집니다. 리뷰 또한 이에 대한 답장의 형태로 이루어지지요. 그런데, 일부 이메일 클라이언트는 ``rich user experience’’ 라는 명목하에 원래 내용을 오염시키곤 합니다. 탭을 스페이스로 바꾸거나 html 코드를 집어넣거나 하는 식이죠. 때문에 패치를 보내는 사람은 자신의 메일 내용이 원래 의도한대로 읽는 사람에게 보내지도록 조심해야합니다....