Victor’s Blog

最近在試用 rxvt-unicode，遇到了一些字寬[1]的問題。於是動手修了 glibc 的 charmaps/UTF-8.gz（Debian 是放在 /usr/share/i18n/charmaps/UTF-8.gz）。如果不想自己動手來，可以下載 http://victor.csie.org/archive/UTF-8.gz，跳到之後的 locale-gen 那段。這是用 Debian 的 glibc 2.3.2.ds1-22 + EastAsianWidth-4.1.0.txt 做出來的。

動手前，請先備份 charmaps/UTF-8.gz。

首先，到 unicode.org 抓一份表格(EastAsianWidth)，這個表裡面定義了亞洲字形的寬度。可參考 http://www.unicode.org/reports/tr11/。

接下來我寫了一個 script 來產生符合 glibc 的 charmaps/XXX.gz 的格式。Script 裡面的 __DATA__ 是我目前 charmaps/UTF-8.gz 的 WIDTH 那段中，所有寬度為零的 range。因為來源有好幾個，所以為了方便，就直接從那邊 copy 過來。

./EastAsianWidth.pl  UTF-8.txt

接著，

cp /usr/share/i18n/charmaps/UTF-8.gz UTF-8.gz
gunzip UTF-8.gz

解開得到 UTF-8 後，開個 editor 把檔案最後面，從 “WIDTH” 一直到 “END WIDTH” 取代成 UTF-8.txt 裡面的東西。再壓好放回去原來的位置：

gzip UTF-8
cp UTF-8.gz /usr/share/i18n/charmaps/UTF-8.gz  # you need root here.

最後，執行 locale-gen，你可能會看到：

# locale-gen
Generating locales...
zh_TW.BIG5... done
zh_TW.UTF-8...
/usr/share/i18n/charmaps/UTF-8:28542: unknown character `U00002614'
/usr/share/i18n/charmaps/UTF-8:28560: unknown character `U0000FAD9'
/usr/share/i18n/charmaps/UTF-8:28564: unknown character `U0000FE19'
/usr/share/i18n/charmaps/UTF-8:28576: unknown character `U0003FFFD'
/usr/share/i18n/charmaps/UTF-8:28579: unknown character `U000E0100'
#

後面的錯誤是說，EastAsianWidth.txt 裡面定義的字，這幾個不在你的 charmaps/UTF-8 裡面。並不是什麼嚴重的問題，可以不理他。

這樣就大功告成了！接下來如果還有問題，就是 Big5 轉碼表跟字型的問題了吧。

[1] urxvt 是用 wcwidth(3)（也就是在 glibc 裡）判斷字寬。

在寫計網作業時，發現如果用 signal(2) 去 override default signal handler，當 accept(2) block 住時，接到了那個 signal，並不會 return 回來。這跟平常沒 override 時，會傳回 -1 並將 errno 設為 EINTR 的情形不同。翻了 > 才發現原因。

在 accept, read 這類的 /slow system call/ 裡面接到 signal 後，當 signal handler return 時，傳回 EINTR。“有些”系統會重新回到該 system call 執行 (現在的 Linux & FreeBSD 都是)，我在想也是因為這個原因，我的 accept 不會 return。

後來，我用 sigaction(2) 取代 signal(2)，sa_flags 不要設 SA_RESTART，就可以如我所願讓 blocked 的 accept 回來了。這個方法在 Linux 跟 FreeBSD 下都 work。

之前看了 <<Linux Kernel Development>> 中談到 Memory Management 那章。今天剛好在 irc 上聊到，這是一點點對 slab 的介紹

22:31  slab 算是 kernel 裡面 kmalloc 的一個 "page (概念上)"
22:32  kernel 裡面會對各種不同的 slab 作 cache 之類的
22:33  slabtop(1) 可以看不同 slab 中的最大值 (對各個欄位)

22:36  slab 的 cache 是這樣的，因為去拿一個新的 slab 的 cost 比較高，
                所以每當有 slab 被 free 掉時，會存起來當 cache
22:37  100% usage 可能是目前站上比較 active :Q
22:38  slab 應該沒有什麼夠不夠的

Ptt’s CPU is eaten a lot in the part of iowait, we thought iowait means disk I/O. But with DMA, why CPU takes such a lot of CPU time?

Trace into the kernel, I found the time of iowait will be added inside io_schedule():

void __sched io_schedule(void)
{
   struct runqueue *rq = &per_cpu(runqueues, _smp_processor_id());

   atomic_inc(&rq->nr_iowait);
   schedule();
   atomic_dec(&rq->nr_iowait);
}

During the context switch from the middle, each time interrupt increase the value if nr_iowait is true. So iowait is no longer the waiting time of I/O. Of course it can be omitted if the process number is small, but ptt has more than 25000 process …

Everybody went home during the Chinese New Year. Gosh, the power of the dorm went off line during this time. My BIOS was set properly, so everything went very well before. But it didn’t this time. My computer was halt for about 10 days @@; After coming back, I found it caused by corrupt ext3. It sucks, non-journal fs can fsck after the booting at least, but my ext3 dead in the loader -_- I won’t use ext3 anymore.