用simplescaler來量某段code的指令數的時候…發現了一個怪怪的地方
→ 每次執行指令數都會不同


什麼鬼?  今天再來找找看問題所在

評估某段code的cpu overhead

1 把演算法寫成 code
2 cross compiler成 ARM binary (因為SSD controller中多半是用ARM)
3 用SimpleScaler來算指令數

------------------------------

目前的code(假設10個users)算出來如下:
1 dispatch request       →  201 道 Inst.   →  0.25 us
2 credits charging        →  52 道 Inst.    → 0.06 us

ps: 假設800Mhz的cpu, CPI = 1 (i.e., as BLAS),  no cache。


0.25us     僅是完成一個page read 的 0.2% (i.e., 0.25/(25+100))
              或僅是完成一個page write 的  0.08% (i.e., 0.25/(200+100))

libgcc_s.so.1 找不到 ， error while loading shared libraries libgcc_s.so.1

為了裝 arm-elf-gcc 不知道為什麼把 shared library搞壞了

很多程式都說 error while loading shared libraries libgcc_s.so.1

用locate指令找了一下 libgcc_s.so.1 發現有三個地方有…

一開始單純的想法是直接把他copy到 /lib之下，但是事情那麼簡單…

為了不負爺爺的聲望，又做了一些check...最後很搞笑的發現 剛剛copy的libgcc_s.so.1

是ARM binanry...  (我是用file cmd去看的)

最後解法: 抓別電腦的 libgcc_s.so.1過來 放進去 /lib中

profiling ARM binary code

先從這下載  ARM-DS5 (好像有試用版啦)

--------------------------
網友

I don't know any free ARM profilers.

You can try ARM RVDS 4.0 Pro. It has a good profiler. And you can use emulator instead of real hardware with it. It simplifies some things, but you'll not receive information about cache-misses/memory-latency, and results may differ from tests on real hardware.

The price of RVDS is high enough. You can try trial for 30 or 45 days, maybe this will be enough to profile all you want.

---------------------------





Oprofile
可以裝一個在ARM機器上，然後跑你要profile的程式時，再同時run Oprofile去監控
和gprof不同的是:

因为gprof只是针对应用层的分析，而oprofile是通过硬件（CPU）本身支持的性能计数器进行的性能分析，贯穿内核到用户应用程序，很有参考价值    URL

idea - prefetch in SSD

把read request所要的data從快gc的channel先prefetch出來…

好處:  reduce latency

方法:1  prefetch 時 prefer 快 GC的 channel
                  → 怎麼判斷 "快GC"       (elem utilization, pended wt req)
                  →要prefetch 什麼 data ? (from history, seq ratio)

實驗log IO trace的錄製 0223

模仿PVR (using intel open tool kit)，以下是參數

1st try
s i   cap  qdep  wr  wrnd  rrnd  str  wrsz  rdsz   warm   test     bw     iops      lat
  0 0  4300     8 100     5   100    1    32    32    5.0 5000.5  17.61      564    14.19
sinhome-desktop: sample 0 iter 0: (test) 88059.59 MB in 5000.46 sec 17.61 MB/sec 

1. 95% seq 
2. 32KB
3. address space 約4.5GB

2nd try

  s i   cap  qdep  wr  wrnd  rrnd  str  wrsz  rdsz   warm   test     bw     iops      lat

  0 0  4500     8 100     0   100    1    32    32    5.0 3000.3  55.84     1787     4.47

sinhome-desktop: sample 0 iter 0: (test) 167530.88 MB in 3000.31 sec 55.84 MB/sec 

post-processing to disksim format

cat inteltoolkit_trace.out | awk '{print ($1-1393167501.968118)*1000" ""0"" "$3" ""64"" ""0"}' > PVR_32KB_5GB.dis

note: output中的address單位是byte !!!

_________________________________________________________________________

postmark的參數

set size 65536 131072

set number 15000

set transactions 5000000

set location /media/benchmarkTarget2

set read 32768

set write 32768

set buffering false

set bias read -1

set bias create 5       // 設5會讓blktrace output長超快，而設10就超慢，待找問題

1. 32KB
2. address space 5GB

post-processing to disksim format

cat tmp3 | awk '{print ($4-6.474369353)*1000" ""0"" "$8" "$10*8" ""0"}' > pm2disksim

加速user1

cat PM_32KB_5GB+PVR_32KB_5GB.dis | awk '{if($6==1) {print $1/15" "$2" "$3" "$4" "$5" "$6} else print $0}' |sort -g -k 1 >PM_32KB_5GB_15m+PVR_32KB_5GB.dis

Exploiting workload dynamics to improve SSD read latency via differentiated error correction codes

   goal:  加快 read page latency (如圖最下方)

   方法:
        如圖最下: 有點像切pipeline。一個pages分成多個segment，如最上方圖(b)，如此，讀第二個         segment的時候就可以同時幫第一個pages做ECC解碼的動作。


   concern:
        ECC size 均分到各個segment之， ECC的能力會變弱…(e.g., 原本能允許整個pages發生16bit的error，現在每個segment最多承受4bit)。  所以要想辦法降低 error rate。 方法:  降低寫入的速度，來提高reliability (也就是減少error rate啦)

    how about write latency ?  不就犧牲太多??
         配套 1 加RAM當 write buffer
                  2 只在有idle time的時候做"慢速寫入"
                      ps: idle time指的是host沒發request來的時候，此處是用估計的…非即時偵測。