Ting 이네 Software 이야기

There is function for sleep in kernel - ex. msleep(). And schedule_timeout() is used in those.
And, schedule_timeout() calculates time for expiration based on current jiffies.
But some functions disable local irq or irq for a while in it.
For example, printk does this - disabling local irq.
But, jiffies is updated based on local timer irq (In case of SMP, one defined core - usually cpu0 - is used.)
So, disabling local irq - for timer core - may prevent system from updating jiffies.
At this moment, calling schedule_timeout() leads to set timer which expiring time is earlier than it should be because jiffies are behind of real time.
So, for example, msleep(100) may wake up after 50ms at this scenario.
This is very dangerous.
But, actually, lots of code uses jiffies directly in kernel.
So, I'm not sure that all those codes are safe in case that jiffies is behind.
Anyway, here is my sample fix for this potential issue of schedule_timeout().
I couldn't find any fix regarding this issue even in kernel-3.0.
So, I'm not sure I missed something.
But, as for me, this is definitely issue to consider when variable jiffies is directly used.
I hope that my sample fix regarding schedule_timeout is helpful for others.
(In my opinion, fundamentally, all codes that uses jiffies directly should be re-examined whether it is really safe or not in case that jiffies is behind.)

diff --git a/include/linux/jiffies.h b/include/linux/jiffies.h
index 6811f4b..6c89958 100644
--- a/include/linux/jiffies.h
+++ b/include/linux/jiffies.h
@@ -290,6 +290,8 @@ extern unsigned long preset_lpj;

 #endif

+extern unsigned long exact_jiffies(void);
+
 /*
  * Convert various time units to each other:
  */
diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
index 56f87fa..37e7bbf 100644
--- a/kernel/time/tick-sched.c
+++ b/kernel/time/tick-sched.c
@@ -99,6 +99,32 @@ static ktime_t tick_init_jiffy_update(void)
        return period;
 }

+/**
+ * exact_jiffies - return real jiffies value
+ *
+ * You can't sure that value from %jiffies varaible is real current time.
+ * Jiffies may not be updated for a while due to several reasones.
+ * So, to get exact value, current ktime and %last_jiffies_update should be used
+ */
+unsigned long exact_jiffies(void)
+{
+       unsigned long exact = jiffies;
+       if (tick_period.tv64
+           && last_jiffies_update.tv64) {
+               unsigned long seq, ticks;
+               ktime_t delta;
+               do {
+                       seq = read_seqbegin(&xtime_lock);
+                       delta = ktime_sub(ktime_get(), last_jiffies_update);
+                       ticks = ktime_divns(delta, ktime_to_ns(tick_period));
+                       /* +1 to compensate loss at division */
+                       exact = jiffies + ticks + 1;
+               } while (read_seqretry(&xtime_lock, seq));
+       }
+       return exact;
+}
+EXPORT_SYMBOL_GPL(exact_jiffies);
+
 /*
  * NOHZ - aka dynamic tick functionality
  */
diff --git a/kernel/timer.c b/kernel/timer.c
index c4714a6..628a714 100644
--- a/kernel/timer.c
+++ b/kernel/timer.c
@@ -1304,7 +1304,6 @@ void run_local_timers(void)
  * without sampling the sequence number in xtime_lock.
  * jiffies is defined in the linker script...
  */
-
 void do_timer(unsigned long ticks)
 {
        jiffies_64 += ticks;
@@ -1457,7 +1456,7 @@ signed long __sched schedule_timeout(signed long timeout)
                }
        }

-       expire = timeout + jiffies;
+       expire = timeout + exact_jiffies();

        setup_timer_on_stack(&timer, process_timeout, (unsigned long)current);
        __mod_timer(&timer, expire, false, TIMER_NOT_PINNED);
@@ -1467,6 +1466,13 @@ signed long __sched schedule_timeout(signed long timeout)
        /* Remove the timer from the object tracker */
        destroy_timer_on_stack(&timer);

+       /*
+        * Reaching here means "timer interrupt is issued
+        *   and 'jiffies' is updated."
+        * So, 'jiffies' here is recently-updated-value
+        *   and 'jiffies' can be directly used
+        *   instead of using 'exact_jiffies()'
+        */
        timeout = expire - jiffies;

  out:

done.

XP자체는 이미 상당히 알려진 방법론이며, 모든 방법론이 그러하듯이 좋은 말들과 장미빛 미래를 제시한다.
때문에, 책을 읽을때, 이런 미사여구들은 필터링 할 필요가 있다.

내가 이해한 관점에서 보면, XP의 실천적 방법론의 핵심은 '사람'과 '테스트'다.
나 역시 여기에 동의하긴 한다.
그렇지만, XP는 나의 견해보다 좀더 극단적인 감이 있다.
어떤 통계적인 근거를 제시할 수 없으니, 내가 맞다는 주장을 펼칠 수는 없지만, '조금 지나치다.'라는 느낌은 분명히 있다.

특히 pair programming부분은 동의하기 어렵다. 이건 철저하게 개인의 성향에 따라 다르다.
어떤 사람은 pair programming에서 더 나은 성과를 보일 수 있겠지만, 그렇지 않은 사람도 분명히 상당수 존재할 것이다.
일단 나 부터가 pair programming에 대한 거부감이 있다.
그래서 난, 이를 약간 완화시킨, 내 나름대로의 방법론을 제시하고 싶다.
"최소한 2인 1팀이 되어 움직이게 한다."

2인 1팀이 하나 혹은 다수의 work item을 공동책임하에 진행하는것... 개인적으로 이런 방식이 더 나아 보인다.
물론 이때, 2인이 소위 사수/부사수 의 관계를 의미하는게 아니다. 완전히 동등한 두 사람을 말한다.
사수/부사수의 방법론은 또 다른 분야이니까 일단 뒤로 하자.

음.. 적다 보니 왠지모르게 미숙한 글의 냄새가 폴폴 풍긴다...쩝..
일단 이쯤에서 접고... 생각나면 다시 업데이트 하자..

* update (2011/Aug/19)
왜 2인 1팀이어야 하는가?
* Pair programming의 효과를 얻을 수 있다. 서로가 서로를 보완하며, review할 수 있다.
* 서로가 서로의 backup이 되어 줄 수 있기 때문이다.
둘 중 누구 하나가 휴가를 가야 한다던가, 갑자기 쉬어야 하는 경우, 다른 한 사람이 그 사람의 빈자리를 채워줄 수 있다.
* 단점 : 전문 분야가 최소한 두곳 이상이 생기게 되므로 업무의 효율이란 측면에서 손실이 있을 수도 있겠으나, 이는 시간이 지나면 해결될 수 있는 문제라고 본다.

음... 오랜만에 게임 하나를 엔딩을 봤다.
사실 옛날에 엔딩을 봤던 게임이긴 한데, 최근에 다시 잡고 해 봤다는...
근데 상당히 재미있었다.
바로 Kingdom Under Fire(KUF).
일반적인 RTS게임에 RPG요소를 추가해서, Hero개념을 추가했다.
Warcraft3보다도 먼저 RTS에 Hero의 개념을 추가했다는...
순수 국산 이기도 하고...

물론, 고질적인 소프트웨어 불법 복제 때문에 안타깝지만 빛을 잃긴 했다...-_-;
여튼... 다시 해봐도 수작임은 분명하다.

그러고 보니 예전에 온게임넷에서 리그도 했었지 아마...
결승이... 전상욱 vs. 강xx 였던걸로 기억하는데 마지막에 건물이 먼저 깨어지느냐 히어로가 먼저 나오느냐의 시간싸움에서 '리히터 로젠하임'의 등장으로 결국 전상욱이 우승했던 기억이 난당...
정말 재미있었던 경기였었고, 그 덕분에 KUF를 아직도 좋아하고 있는지도 모르겠당...
여튼... 추천할 수 있는 작품...