コグノスケ

未来から過去へ表示(*) link

過去から未来へ表示

もっと前

2014年9月1日 >>> 2014年8月19日

もっと後

2014年9月1日

permalink

編集する

Linux 3.14.16動作on自作ARMエミュ

目次: Linux

自作ARMエミュレータ上でLinux 3.14.16も起動しました。

実行速度が遅いのは相変わらずですが、ちょっとしたキャッシュを入れたおかげで、従来比2倍くらいになりました。下記はCore2 Quad Q9550での実行結果です。

Linux 3.14.16起動ログon自作ARMエミュレータ

Connected to the target VM, address: '127.0.0.1:59905', transport: 'socket'

Exception: Reset by 'Init.'.
loadFile: Z:\arm_cross\linux-3.14.16\arch\arm\boot\Image
loadFile: 'Z:\arm_cross\linux-3.14.16\arch\arm\boot\Image' done, 3912512bytes.
loadFile: Z:\arm_cross\work\initramfs.gz
loadFile: 'Z:\arm_cross\work\initramfs.gz' done, 1113122bytes.
UARTFBRD: 0x00000004
UARTIBRD: 0x00000027
UARTLCR_H: 0x00000070
[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 3.14.16+ (katsuhiro@falcon) (gcc version 4.9.1 20140710 (prerelease) (crosstool-NG linaro-1.13.1-4.9-2014.07 - Linaro GCC 4.9-2014.07) ) #7 Tue Sep 2 00:29:04 JST 2014
[    0.000000] CPU: ARM926EJ-S [41069260] revision 0 (ARMv5TEJ), cr=00003137
[    0.000000] CPU: VIVT data cache, VIVT instruction cache
[    0.000000] Machine: ARM-Versatile PB
[    0.000000] Ignoring unrecognised tag 0x00000000
[    0.000000] Memory policy: Data cache writeback
[    0.000000] On node 0 totalpages: 16384
[    0.000000] free_area_init_node: node 0, pgdat c03c2c18, node_mem_map c3f7a000
[    0.000000]   Normal zone: 128 pages used for memmap
[    0.000000]   Normal zone: 0 pages reserved
[    0.000000]   Normal zone: 16384 pages, LIFO batch:3
[    0.001122] sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 178956969942ns
[    0.007939] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
[    0.009354] pcpu-alloc: [0] 0 
[    0.016694] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 16256
[    0.017822] Kernel command line: console=ttyAMA0 mem=64M lpj=0 root=/dev/ram init=/bin/sh debug printk.time=1
[    0.034226] PID hash table entries: 256 (order: -2, 1024 bytes)
[    0.037649] Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
[    0.051346] Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
[    0.171196] Memory: 59872K/65536K available (2809K kernel code, 156K rwdata, 732K rodata, 115K init, 116K bss, 5664K reserved)
[    0.176299] Virtual kernel memory layout:
[    0.176299]     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
[    0.176299]     fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
[    0.176299]     vmalloc : 0xc4800000 - 0xff000000   ( 936 MB)
[    0.176299]     lowmem  : 0xc0000000 - 0xc4000000   (  64 MB)
[    0.176299]     modules : 0xbf000000 - 0xc0000000   (  16 MB)
[    0.176299]       .text : 0xc0008000 - 0xc037d840   (3543 kB)
[    0.176299]       .init : 0xc037e000 - 0xc039ac8c   ( 116 kB)
[    0.176299]       .data : 0xc039c000 - 0xc03c3340   ( 157 kB)
[    0.176299]        .bss : 0xc03c3340 - 0xc03e0694   ( 117 kB)
[    0.194996] NR_IRQS:224
[    0.311103] VIC @f1140000: id 0x00041190, vendor 0x41
[    0.334340] FPGA IRQ chip 0 "SIC" @ f1003000, 13 irqs, parent IRQ: 63
[    0.421699] Console: colour dummy device 80x30
[    0.426511] Calibrating delay loop... 15.18 BogoMIPS (lpj=75904)
[    1.453855] pid_max: default: 32768 minimum: 301
[    1.470559] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
[    1.471997] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes)
[    1.549273] CPU: Testing write buffer coherency: ok
[    1.567848] Setting up static identity map for 0x802ac900 - 0x802ac958
[    1.792641] VFP support v0.3: no double precision support
[    1.826380] NET: Registered protocol family 16
[    1.913054] DMA: preallocated 256 KiB pool for atomic coherent allocations
[    2.222332] Serial: AMBA PL011 UART driver
[    2.232115] dev:f1: ttyAMA0 at MMIO 0x101f1000 (irq = 44, base_baud = 0) is a PL011 rev1
[    2.471302] console [ttyAMA0] enabled
[    2.506242] dev:f2: ttyAMA1 at MMIO 0x101f2000 (irq = 45, base_baud = 0) is a PL011 rev1
[    2.542220] dev:f3: ttyAMA2 at MMIO 0x101f3000 (irq = 46, base_baud = 0) is a PL011 rev1
[    2.580195] fpga:09: ttyAMA3 at MMIO 0x10009000 (irq = 70, base_baud = 0) is a PL011 rev1
[    3.207538] bio: create slab <bio-0> at 0
[    3.444611] Switched to clocksource timer3
[    4.365563] NET: Registered protocol family 2
[    4.453045] TCP established hash table entries: 1024 (order: 0, 4096 bytes)
[    4.465491] TCP bind hash table entries: 1024 (order: 0, 4096 bytes)
[    4.474190] TCP: Hash tables configured (established 1024 bind 1024)
[    4.482792] TCP: reno registered
[    4.485464] UDP hash table entries: 256 (order: 0, 4096 bytes)
[    4.493590] UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
[    4.522323] NET: Registered protocol family 1
[    4.552290] RPC: Registered named UNIX socket transport module.
[    4.555861] RPC: Registered udp transport module.
[    4.559377] RPC: Registered tcp transport module.
[    4.562420] RPC: Registered tcp NFSv4.1 backchannel transport module.
[    4.599499] Trying to unpack rootfs image as initramfs...
[   41.046708] Freeing initrd memory: 1084K (c0800000 - c090f000)
[   41.069328] NetWinder Floating Point Emulator V0.97 (double precision)
[   41.141637] futex hash table entries: 256 (order: -1, 3072 bytes)
[   41.206487] Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
[   41.221841] jffs2: version 2.2. (NAND) Â© 2001-2006 Red Hat, Inc.
[   41.248434] ROMFS MTD (C) 2007 Red Hat, Inc.
[   41.252843] msgmni has been set to 119
[   41.288910] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 254)
[   41.292702] io scheduler noop registered
[   41.294993] io scheduler deadline registered
[   41.299488] io scheduler cfq registered (default)
[   42.651584] brd: module loaded
[   42.698604] physmap platform flash device: 04000000 at 34000000
[   42.799677] physmap-flash physmap-flash.0: map_probe failed
[   42.938847] smc91x: not found (-19).
[   42.980983] mousedev: PS/2 mouse device common for all mice
[   43.023922] ledtrig-cpu: registered to indicate activity on CPUs
[   43.175215] TCP: cubic registered
[   43.177334] NET: Registered protocol family 17
UARTIFLS: 0x00000012
UARTFBRD: 0x00000000
UARTIBRD: 0x00000001
UARTLCR_H: 0x00000000
UARTFBRD: 0x00000000
UARTIBRD: 0x00000000
UARTLCR_H: 0x00000070
UARTFBRD: 0x00000004
UARTIBRD: 0x00000027
UARTLCR_H: 0x00000070
[   43.361101] Freeing unused kernel memory: 112K (c037e000 - c039a000)
hello, world!!
/bin/sh: can't access tty; job control turned off
UARTFBRD: 0x00000004
UARTIBRD: 0x00000027
UARTLCR_H: 0x00000070
/ #

実行速度が速いと時間当たりの試行回数を増やせて、デバッグ効率が良くなるので、実行速度って結構、大事だったりします。

ハングしていたところ

以前、ハングしていた箇所はPL110 Color LCDドライバでした。今のところカーネルコンフィグを変え、PL110ドライバをコンパイル対象から外すことで、ハングを回避しています。

それだけで1週間掛かっちゃう？って思った方はスルドイです…。本当のところを言うと「ハングはイケてないぜ、直すぜー！」と思ってPL110のLinuxドライバのコードを見ていましたが、どう直したもんかわからず、諦めたのです…。

なぜかPL110のドライバはPL110とPL111（次世代コア）のレジスタアドレスが両方書いてあって、どちらのコア用の制御なのかがわかりませんでした。一応、どちらの仕様書も持っていますから、最悪、両方作って試せば良いのですけど、さすがに面倒すぎる…。

おそらく私が何か勘違いしているだけの可能性大なのと、LCDのエミュレーションはまだやるつもりがないので、この件は頭の隅で細々と考えることにします。

編集者:すずき(2024/03/05 02:28)

コメント一覧

コメントはありません。

この記事にコメントする

2014年8月26日

permalink

編集する

hprofプロファイラ

Javaのhprofというプロファイラは、準備を必要とせず（JDK標準だから）に、CPU、ヒープ、モニタの衝突など、一通り測れる便利なプロファイラです。

特に各メソッドのカウントを「全て取る」モード（-Xrunhprof:cpu=times）は、明らかに呼び過ぎのメソッドが一発で分かるため、大変に便利です。

しかし便利な反面、実行速度が下がりすぎて使い物にならなくなる場合があります。

今日遭遇したケースは、7MBのファイルをDataInputStreamからreadByte() するプログラムです。通常のデバッグ実行であれば、ほんの一瞬で終わりますが、cpu=timesでプロファイリングすると10分経っても終わりません…。

どうも、細かいメソッドが頻繁に呼ばれすぎるせいで、メソッド呼び出しのカウントを行う部分がパンクしているようです。

思い出してみればInputStream系はInputStream -> BufferedInputStream -> DataInputStreamなどのように連鎖させるのでメソッド呼び出しが深く、データをロードするという処理はループ回数が多くなりがちなので、深さ×ループ回数の掛け算に比例してどんどん遅くなってしまいます。

これはよろしくありません。

頑張って軽くするには

待てるくらいの時間に収まるように、何とか軽くしてみましょう。

まず目を付けたのはreadByte() です。readByte() で1バイトつずつ読むから呼び出しカウントが多くなるわけです。ならばreadLong() で8バイトずつ読めばカウントは1/8です。

コードもちょい変えで済むし、お手軽高速化としては、プロファイリング時の実行速度もほぼ8倍になる、という中々の効果です。

しかしreadLong() を持ってしても100MBオーバーとなると厳しいでしょう。もし本当にそこまで必要なら、根底から覆す（InputStreamを使わないとか）別の手立てを考える必要がありそうです。

編集者:すずき(2014/08/26 03:15)

コメント一覧

IKeJIさん(2014/08/26 17:13)
BufferedInputStreamのうしろは何回もは呼ばれないのでは？
すずきさん(2014/08/26 21:43)
＞IKeJI さん
そうか、確かに BufferedInputStream 以降はあまり呼ばれないから、BufferedInputStream のバックエンドは呼び出し回数にほとんど関係無いですね。すみません、間違ってました。

ただ BufferedInputStream 自体が結構遅くて、readByte() だとつらいという点は変わりません。
試しに DataInputStream(new BufferedInputStream(new FileInputStream())) に対して、readLong() で 30万回読みだしてみますと、

count : method
307547 : java.io.BufferedInputStream.read
307547 : java.io.DataInputStream.readLong
307547 : java.io.DataInputStream.readFully
307567 : java.io.BufferedInputStream.read1
307568 : java.io.BufferedInputStream.getBufIfOpen
307894 : java.io.BufferedInputStream.getBufIfOpen
301 : java.io.FileInputStream.read
3584 : java.io.BufferedInputStream.read
301 : java.io.BufferedInputStream.fill

こんな感じになっていて、getBufIfOpen がプロファイリングを激しく邪魔します。
IKeJIさん(2014/08/27 00:42)
なるほど。
その辺のprivateなメソッドはインライン展開できそうなもんですが、何かできない理由があるんですかね？
BufferedInputStream.readをfinalにしたら早くなるんだろうか？
すずきさん(2014/08/27 02:09)
＞IKeJI さん
BufferedInputStream をコピーした OreBufferedInputStream を作って、read を final にして試してみました。

（final にする前）
count method
616787 net.katsuster.semu.arm.OreBufferedInputStream.read
616787 java.io.DataInputStream.readFully
616787 java.io.DataInputStream.readLong
616787 net.katsuster.semu.arm.OreBufferedInputStream.read1
616787 net.katsuster.semu.arm.OreBufferedInputStream.getBufIfOpen
617390 net.katsuster.semu.arm.OreBufferedInputStream.getBufIfOpen
603 java.io.FileInputStream.read
2 java.io.FileInputStream.<init>
3584 java.io.BufferedInputStream.read
896 java.io.DataInputStream.readInt
3584 java.io.BufferedInputStream.getBufIfOpen

（final にした後）
616787 net.katsuster.semu.arm.OreBufferedInputStream.read
616787 java.io.DataInputStream.readFully
616787 java.io.DataInputStream.readLong
616787 net.katsuster.semu.arm.OreBufferedInputStream.read1
617390 net.katsuster.semu.arm.OreBufferedInputStream.getBufIfOpen
616787 net.katsuster.semu.arm.OreBufferedInputStream.getBufIfOpen
603 java.io.FileInputStream.read
3584 java.io.BufferedInputStream.getBufIfOpen
2 java.io.FileInputStream.<init>
896 java.io.DataInputStream.readInt

速度も変わらないですね。
IKeJIさん(2014/08/27 13:32)
DataInputStreamがOreBufferedInputStreamをInputStreamとして扱っているからでしょうか？
すずきさん(2014/08/28 10:11)
＞IKeJI さん
もしかして JIT でインライン展開されようとされまいと、関数呼び出しカウントは行われるんじゃないですかね？
BufferedInputStream.read が遅いわけではないので、単にカウントが遅いのでは。
IKeJIさん(2014/08/28 14:26)
そうですが、プロファイルしない時の実行速度はあがるのでは？ > 関数呼び出しカウントは行われる
すずきさん(2014/08/29 17:02)
＞IKeJI さん
プロファイルするときと、しないときとで、JIT の動作が変われば、インライン展開されそうなメソッドなのに、プロファイラにカウントされる理由が付きますかね…？
うーむ、でも自分で書いておいてなんですが、そこまでやらないよな…さすがに…。

この記事にコメントする

2014年8月24日

permalink

編集する

壊れないとしか言ってない

私のスマホは防水だけど、その意味は雨でも壊れない、であって、雨でも使える、って意味ではないんだなあ。

なぜなら、タッチパネルに水滴が着くとまともに動かないからです…。

メモ: 技術系の話はFacebookから転記しておくことにした。

編集者:すずき(2015/11/29 06:08)

コメント一覧

コメントはありません。

この記事にコメントする

2014年8月22日

permalink

編集する

ARMv5とARMv7アーキテクチャの名前について

ARMアーキテクチャを表すときARMv5Tがあって、ARMv6Tがないのはなぜでしょう？

ARMv5TのTの部分は「バリアント」と呼ばれ、TバリアントであればTHUMB命令セットに対応したARMアーキテクチャである、ことを示します。他にもエンハンストDSP命令のEとか、Jazzele命令のJがあります。

ARMv5まではTHUMB命令セットへの対応はオプションでした。このため、ARMv5世代のARMアーキテクチャはTHUMB非対応のARMv5とTHUMB対応のARMv5Tの2種類が存在し得ました。実際にTHUMB未対応のARMv5プロセッサを作った会社があるか、まではわかりませんが。そういうプロセッサを「作っても良い」ことにはなっていました。

例えば、携帯でよく使われていたARM926EJ-SプロセッサのアーキテクチャはARMv5TEJ、つまりTHUMBとエンハンストDSPとJazzeleに対応したアーキテクチャ、という意味です。

しかしARMv6からはTHUMB対応が必須となり、THUMBの有り/無しを区別する必要がなくなり、名前もARMv6のみとなりました。ARMv6はTHUMB命令セットに対応していてもARMv6Tとは呼びません。対応している機能を全部並べ始めると、冗長になるためでしょう、たぶん。

なお、エンハンストDSP命令もv6でARM命令セットに取り込まれたため、Tと同時にEバリアントも消滅しています。

ARMv7以降

さらに、最近のARMv7アーキテクチャでは、バリアントの考えが変わったようで、ARMv7の後ろに対応機能を意味するアルファベットは付かなくなりました。

種類もARMv7-AとARMv7-RとARMv7-Mの3つです。それぞれ「アプリケーション」「リアルタイム」「マイクロコントローラ」プロファイルの意味だそうです。対応する機能は下記の通り。

A: MMU、ARM、Thumb、Thumb-2、Thumb-2EE、NEON、32ビットSIMD
R: ARM、Thumb、Thumb-2（オプション）、VFP、32ビットSIMD、ハードウェア除算
M: Thumb-2、ハードウェア除算

アーキテクチャが対応する命令セットの規模順に並べたとき、ARMとなるところもまたニクいですね。イギリス人はこういうシャレが好きなのでしょうか？

これ以上の詳細情報はARMのサイト（ARMのサイトへのリンクを張っておきます）をご覧ください。

ARM命令セットとTHUMB命令セットの関係

余談ですが、ARM命令セットやTHUMB命令セットにもバージョンがあります。下記の通りです。

ARMv6 : THUMBv3
ARMv5 : THUMBv2
ARMv4 : THUMBv1

バージョンは1:1に対応しており、異なる世代を組み合わせること、たとえばARMv6とTHUMBv2を組み合わせることはできません。

メモ: 技術系？の話はFacebookから転記しておくことにした。なおARMv7の節は8/25に加筆。

編集者:すずき(2014/08/26 01:12)

コメント一覧

コメントはありません。

この記事にコメントする

2014年8月21日

permalink

編集する

マウス壊れた

一昨年買った（2012年4月5日の日記参照）、Logicool Perfomance MX M950が壊れました。マウスの左ボタンがバカになって、全部ダブルクリックになってしまう、良くある壊れ方です。

形あるもの、いつか壊れるとは思っていますが、1万以上したマウスが2年で壊れるのはちょっと悲しい。

Newマウス2号

存外に早く壊れた以外、使い勝手は最高に気に入っていたので、もう一個M950を買いました。アマゾンで8,226円でした。前回は12,000円したので、3割近く安くなっていますね。

しかし2年前のフラッグシップモデルだったM950が、未だにフラッグシップモデルとして君臨しているのはちょっと意外でした。余程の人気なのか、それとも新製品開発をあまりしていないのでしょうか。

Logicoolマウス愛好者としては、後者でないことを祈るばかりです。

保証期間

新たにやってきたM950の保証書を見てびっくり。保証期間「ご購入日から3年間」の文字が輝いています。

さ、3年…だと…？ということは、壊れたマウスは保証期間内？無料で直せちゃう感じ？マジで…？

普通のメーカー保証は1年で速攻切れる役立たずなイメージですが、3年ってすごいですね。さすがだなLogicoolさん。でも、もう保証書がどっか行ってしまったから、何年でも意味なかったりするのだけど…。今度は大事に取っておきます。

編集者:すずき(2014/08/21 23:24)

コメント一覧

hdkさん(2014/08/22 01:11)
ロジクールの 1,500 円もしないマウスがなぜか 5 年保証で、1 年ちょっとでボタンのチャタリングが出たことがあったんですが、購入店で修理に出したら 1 か月かかって新品交換されてきました。交換後 5 年以上たっていますがチャタリングはもう出ていないので、個体差があるんですかねぇ。
すずきさん(2014/08/23 01:42)
＞hdk さん
今まで使ってきたマウスも長持ちが多かったので、偶然外れを引いたのだと思います。
しかし 5年は長すぎではなかろうかｗ

この記事にコメントする

2014年8月20日

permalink

編集する

ファイルシステム対決

CentOS7 EXT4 vs XFS vs Btrfs vs ZFS on vda - Qiita を読んで。

参考になります（※1）。ZFSはFUSE経由じゃないNative実装があるのか…知らなんだ。

（※1）補足。この手のベンチマークはたくさんあるように見えて、ファイルシステム側の進化が早いため、すぐに陳腐化します。なので、新しいベンチマークは常にありがたいものです。

XFSは1MB overのデカいファイルは速いけど、1KBくらいの細かいファイルのcreate/deleteをぶちかます（カーネルのtarballを展開しながら、古いカーネルソースをrm -rするとか）と、すっごい遅くて嫌になって使うの辞めた記憶があるのだけど…改善されたのだろうか？

メモ: 技術系？の話はFacebookから転記（※2）しておくことにした。

（※2）本来8月14日のエントリです。8月14日辺りでエミュレータが動いたのが嬉しくて、浮かれてFacebookに書きまくったら、このサイトに転記しきれなくなったため、未来のエントリに移動させています。

編集者:すずき(2014/08/16 16:40)

コメント一覧

コメントはありません。

この記事にコメントする

2014年8月19日

permalink

編集する

C言語はいくらでもメチャクチャに書ける

目次: C言語とlibc

switch文を使ってはいけないを読んで。

PHPはさておいて。私もswitchよりStateパターンを選びますが、C言語の関数ポインタでStateパターンを実現するのは、今も迷います。言語仕様上、悪い方に倒れるのを阻止できないためです。

ハッカーが明確で読みやすいコードを書いてくれるうちは良いですが、頭のおかしい人がdoという関数ポインタに全関数を入れるクソコードを書き始めたらもう全部パアです。

いやまさかそんなこと、と思うかもしれませんが、どこの会社とは言いませんがそんなクソコードが実在してるんですよ、世の中って怖いですよね…。

ワルいコード

この記事（コードのネストを深くするな）を読んでいたら、会社のクソコード山脈を思い出しました。

7段ifなんて序の口。世の中の悪手とされる書き方は、大概やってるワルい奴です。バグも多い…。

メモ: 技術系？の話はFacebookから転記（※）しておくことにした。

（※）本来8月14日のエントリです。8月14日辺りでエミュレータが動いたのが嬉しくて、浮かれてFacebookに書きまくったら、このサイトに転記しきれなくなったため、未来のエントリに移動させています。

編集者:すずき(2023/04/29 21:49)

コメント一覧

すずきさん(2014/08/18 11:44)
C 言語だと do はキーワードなので、変数名としては使えないので、exec ですかね…。文意に変わりはありませんけど。
IKeJIさん(2014/08/26 17:08)
main = 195;
みたいなもんですか？
すずきさん(2014/08/26 21:20)
＞IKeJI さん
コードゴルフなら超短い、その手があったか！など発見や感動がありますが、クソコードは無駄に長いし、発見もないです。
まあ、良くこんなのメンテナンスできますわねー、って違う意味での感動はありますけど…。