RCU: 포인터를 바꾸는 시점과 객체를 해제하는 시점

같은 값을 읽게 하는 기능인가요?

두 CPU가 서로 다른 시점에 읽었다면 서로 다른 버전을 볼 수 있습니다. RCU는 모든 reader가 한 번에 같은 값으로 바뀌도록 맞추는 장치가 아닙니다. 여기서는 공유 포인터 하나가 가리키는 객체를 새 객체로 교체하는 예를 다룹니다. 핵심은 예전 객체를 이미 읽고 있던 코드가 끝나기 전에 그 메모리를 해제하지 않는 것입니다.

갱신하는 코드끼리의 충돌은 별도로 막아야 합니다. writer가 하나뿐이라는 조건을 두거나 mutex 등으로 갱신 순서를 정합니다. reader가 RCU 읽기 구간에 들어갔다고 writer의 포인터 교체가 금지되는 것은 아닙니다. RCU 사용 시 갱신·수명 조건

공유 포인터와 CPU의 지역 포인터를 구분합니다

grace period는 기존 읽기 구간이 끝났음을 확인하는 기간입니다. 임의로 몇 ms를 쉬는 것과 다릅니다. synchronize_rcu()가 기다리는 것은 호출 전에 진행 중이던 읽기 구간이며, 이후 시작한 모든 reader의 종료까지 반드시 기다리는 것은 아닙니다. RCU의 공개·제거·회수 순서

읽는 코드가 보호받는 범위

다음은 설명용 예제입니다. 객체는 공개한 뒤 필드를 바꾸지 않고, 교체와 해제는 아래 writer 경로에서만 수행한다고 가정합니다. 값 10과 20은 실제 커널 설정값이 아닙니다.

struct policy {
    int threshold;
};
static struct policy __rcu *current_policy;
static DEFINE_MUTEX(policy_lock);

int read_threshold(void)
{
    struct policy *p;
    int value = -1;

    rcu_read_lock();
    p = rcu_dereference(current_policy);
    if (p)
        value = p->threshold;
    rcu_read_unlock();
    return value;
}

rcu_dereference()는 최신 버전을 반드시 받게 하거나 참조 횟수를 자동 증가시키는 함수가 아닙니다. 읽기 구간 밖에서도 객체를 써야 한다면 그 자료구조가 정한 안전한 참조 취득 절차가 추가로 필요합니다. RCU 포인터·읽기 구간 API

초기화 → 공개 → 대기 → 해제를 읽습니다

int replace_threshold(int threshold)
{
    struct policy *next, *old;

    next = kmalloc(sizeof(*next), GFP_KERNEL);
    if (!next)
        return -ENOMEM;
    next->threshold = threshold;

    mutex_lock(&policy_lock);
    old = rcu_dereference_protected(current_policy,
                                   lockdep_is_held(&policy_lock));
    rcu_assign_pointer(current_policy, next);
    mutex_unlock(&policy_lock);

    synchronize_rcu();
    kfree(old);
    return 0;
}

이 코드는 include, 초기 사용자 연결, 모듈 종료 처리를 생략한 예제입니다. 모든 writer가 policy_lock을 사용하고 모든 reader가 위 규칙을 지켜야 합니다. 해제한 old를 다른 곳에서 따로 보관하는 구조에는 그대로 적용할 수 없습니다. 포인터 공개와 synchronize_rcu API

call_rcu와 SRCU는 어느 부분이 다릅니까?

SRCU도 읽기 구간 안에서 자기 종료를 기다리는 synchronize_srcu()를 호출해도 된다는 뜻은 아닙니다. srcu_read_lock()이 반환한 값을 맞는 srcu_read_unlock()에 그대로 넘겨야 하며, 일반 RCU와 SRCU의 대기를 섞어 객체 수명을 보장했다고 판단하면 안 됩니다. SRCU domain과 blocking 조건 SRCU 읽기 API

RCU stall은 어디서 진행이 막혔다는 뜻인가요?

stall 경고는 grace period 진행이 예상보다 늦다는 단서입니다. RCU 구현 자체가 잘못됐다는 판정은 아닙니다. interrupt를 오래 막은 루프, 실행 기회를 얻지 못한 RCU thread, 긴 handler, 과도한 콘솔 출력, timer 문제도 조사 대상입니다.

경고를 끄거나 timeout만 늘리면 메시지는 줄어들 수 있지만 막힌 실행이 복구됐다는 근거는 되지 않습니다. 커널 버전과 설정, 최초 경고, 반복 stack, 직전에 바꾼 driver를 함께 남기고 관찰 도구 자체의 부하도 고려합니다. RCU CPU stall 원인과 로그 해석

이어서 읽기

• 완료 통지와 객체 수명
• interrupt 이후의 실행 문맥
• 최초 오류와 후속 로그
• 독자가 빠져나왔는지 추적할 기반을 만듭니다