Sun Microsystems 最大のリストラ
■ このスレッドは過去ログ倉庫に格納されています
0001名無しさん＠お腹いっぱい。
2006/06/05(月) 14:32:59【前スレ】
Sun Microsystems 最大の重複
http://pc8.2ch.net/test/read.cgi/unix/1141840635/
0396名無しさん＠お腹いっぱい。
2006/07/27(木) 23:22:59どうせならAMDに買い取ってほしい。
0397名無しさん＠お腹いっぱい。
2006/07/28(金) 00:57:35spinlock したら二重に性能低下するだろ。根本的に CMT (or VMT) を分かってないな
0398名無しさん＠お腹いっぱい。
2006/07/28(金) 07:15:390399名無しさん＠お腹いっぱい。
2006/07/28(金) 10:28:50SMP や CMT に対する理解というのはこの程度だってことだろうね。
まあ、ここまでひどい妄想にしがみついて悔しまぎれなデタラメを
いつまでも引っ張る人物も初めて見たけど。幼稚過ぎ。恥ずかしくないのかね?
日頃からウソにウソを重ねてでも自分の主張通すようなことやってるんだろうな。
0400名無しさん＠お腹いっぱい。
2006/07/28(金) 12:20:26あー、NiagaraというかSPARCは、キャッシュのコヒーレンシプロトコルと連携したロックのための機構を備えてないのな。
スピンロックするには、ビジーウェイトするっきゃないのか。それじゃぁダメだ。論外だ。
0401名無しさん＠お腹いっぱい。
2006/07/28(金) 14:06:140402名無しさん＠お腹いっぱい。
2006/07/28(金) 14:45:40最終手段ですな。
0403名無しさん＠お腹いっぱい。
2006/07/28(金) 14:57:17ソラリスってスピンロックじゃなくてアダプティブロックなんじゃなかったっけ
>spinlock したら二重に性能低下するだろ。根本的に CMT (or VMT) を分かってないな
これはIntelからハイパースレッディングが出たとき、Linuxを動かすとパイプラインが
埋まって性能が低下してしまうバグと同じ事を言っていると理解して良いんだよね?
0404名無しさん＠お腹いっぱい。
2006/07/28(金) 15:01:22切り換えをするようなロックも、Niagaraならspin lockに書き換えることができる
って言ってるの？
0405名無しさん＠お腹いっぱい。
2006/07/28(金) 15:48:24門外漢が気にする問題じゃないよ
0406名無しさん＠お腹いっぱい。
2006/07/28(金) 16:26:34メタばなしはできりゃ避けたいけどさ、メタ方向へ持って行かざるを得ない場合が
まれにある。2ch は多いかも..
なんせここまで内容がおバカだと。
0407名無しさん＠お腹いっぱい。
2006/07/28(金) 16:27:290408名無しさん＠お腹いっぱい。
2006/07/28(金) 17:13:17ttp://tbk.fameflame.dk/videos/2006_Formel_BMW_Deutchland_Race2_MPEG1.mpg
0409名無しさん＠お腹いっぱい。
2006/07/29(土) 00:37:22所詮、単純な Edge Server 専用機だな。
0410名無しさん＠お腹いっぱい。
2006/07/29(土) 04:48:08Niagara向き、不向きの処理があるので、スループット向きじゃないものは、
(一般)SPARCか、Opteronにするんじゃないの？ 現実は、用途にあわせて、
これらのハードを組み合わせるのかな？
そうなると、コンピュータ＝汎用機という発想ではないね。
時代の移り変わりなのか、サンが変わっているのか。。。
0411名無しさん＠お腹いっぱい。
2006/07/29(土) 13:10:050412名無しさん＠お腹いっぱい。
2006/07/29(土) 13:20:370413名無しさん＠お腹いっぱい。
2006/07/29(土) 14:13:43Itaniumの人とか雇ったのは、そのためじゃないかと
0414名無しさん＠お腹いっぱい。
2006/07/29(土) 15:55:59OBPやらドライバ等整備しなくちゃならないから単にSPARC刺しただけでは動かないだろうけど
0415名無しさん＠お腹いっぱい。
2006/07/29(土) 18:11:190416名無しさん＠お腹いっぱい。
2006/07/29(土) 19:02:25SMPにしなければいいのですよ。
OpteronとSPARCの混成にして、
ブートや入出力はOpteronに任せればいい。
0417名無しさん＠お腹いっぱい。
2006/07/29(土) 20:41:320418名無しさん＠お腹いっぱい。
2006/07/31(月) 23:05:19もはや書き込むものすらいない。
それがSunMicrosystems。
0419名無しさん＠お腹いっぱい。
2006/08/01(火) 07:17:190420名無しさん＠お腹いっぱい。
2006/08/01(火) 22:41:230421名無しさん＠お腹いっぱい。
2006/08/01(火) 22:58:010422名無しさん＠お腹いっぱい。
2006/08/02(水) 12:04:15共倒れ、無計画な拡張、などが適当かと。
0423名無しさん＠お腹いっぱい。
2006/08/02(水) 15:48:58> あー、NiagaraというかSPARCは、キャッシュのコヒーレンシプロトコルと
> 連携したロックのための機構を備えてないのな。
> スピンロックするには、ビジーウェイトするっきゃないのか。
> それじゃぁダメだ。論外だ。
って何を言っているの？
IntelのペンCPUのような（コアはシラン）SMP用の同期ロックを言っているのだと
したら、むしろIntelのペンの方ができそこないと思うのだが。
大体、「キャッシュのコヒーレンシプロトコルと連携したロックのための機構」なんて
持っていたら、性能が劣化してしまって大規模構成には使えないと思うが。。
0424名無しさん＠お腹いっぱい。
2006/08/02(水) 17:30:160425名無しさん＠お腹いっぱい。
2006/08/02(水) 19:36:11自社製品を多く買ってくれるところが、そりゃ真のパートナーだわさ
0426名無しさん＠お腹いっぱい。
2006/08/02(水) 22:26:17同一コアで実行しているスレッドがロックを握っている場合と、
他のコアで実行しているスレッドがロックを握っている場合があるが、
コア数の増加とともに、後者の確率が高くなる。
ビジーウェイトでポーリングしているメモリの内容が変わるときには、
キャッシュコヒーレンシのためのメカニズムによって内容の変更が通知されてくるので、
馬鹿正直にポーリングせずに、メモリの内容が変更されたらロードするという命令があればいい。
0427名無しさん＠お腹いっぱい。
2006/08/03(木) 06:58:28X4600とかもこれから売り出すんだし。
0428名無しさん＠お腹いっぱい。
2006/08/03(木) 08:54:53400の言うことと関連しているのかは分からないけれど、
> ビジーウェイトでポーリングしているメモリの内容が変わるときには、
> キャッシュコヒーレンシのためのメカニズムによって内容の変更が通知されてくるので、
> 馬鹿正直にポーリングせずに、メモリの内容が変更されたらロードするという命令があればいい。
「メモリの内容が変更されたらロードするという命令があればいい」というところが
よく分からないのだけれど。
0429名無しさん＠お腹いっぱい。
2006/08/03(木) 12:04:360430名無しさん＠お腹いっぱい。
2006/08/03(木) 16:37:14純粋に好奇心から質問
cas命令みたいなのを使ってOSのロックを実装すれば
いいという理解でいいの?
OSのロックを実装するのにメモリのロックは必要ないと．
だからOSのロックの話と混ぜるのは無意味なので，
ロックの最適化よりも沢山のCPUを効率的に使う最適化の方が重要と．
0431名無しさん＠お腹いっぱい。
2006/08/03(木) 17:45:31メモリの内容が変更されるまで待って変更後の値をロードする命令ってことだろ。
メモリからのロードが、キャッシュにヒットしていない場合に、
メモリからキャッシュへのフィルが終わるまで他のスレッドに実行を譲り、
フィルが終わったらロードして実行を再開するNiagaraとの親和性は高いと思う。
0432名無しさん＠お腹いっぱい。
2006/08/03(木) 17:53:06CASよりLL/SC的なことを言っているんじゃないの?
ただthread IDとbindするわけにいかないから、結局pollingだけどね。
少なくともcoreの外では。
0433名無しさん＠お腹いっぱい。
2006/08/03(木) 17:57:53fetchを減らす努力をする方向だよ。
http://lse.sourceforge.net/locking/rcupdate.html
http://www-06.ibm.com/jp/developerworks/java/041203/j_j-jtp11234.html
0434名無しさん＠お腹いっぱい。
2006/08/03(木) 18:00:21SPARCv8 や MBus、それかもういっこ前の XDBus, XBus の設計解説した記事とか
参考になると思うよ。
おそらく Niagara とはなんの関わりもないと思うw
0435名無しさん＠お腹いっぱい。
2006/08/03(木) 18:34:53http://www.sparc.org/japanese/resource.htm
0436名無しさん＠お腹いっぱい。
2006/08/03(木) 23:43:35これと、次とに、何となくギャップを感じる。なぜ「命令」じゃないと
いけないのだろう？ というか、「命令」ではまずいのじゃないの？
> メモリの内容が変更されるまで待って変更後の値をロードする命令ってことだろ。
↑
↓
> メモリからのロードが、キャッシュにヒットしていない場合に、
> メモリからキャッシュへのフィルが終わるまで他のスレッドに実行を譲り、
> フィルが終わったらロードして実行を再開するNiagaraとの親和性は高いと思う。
0437名無しさん＠お腹いっぱい。
2006/08/04(金) 01:55:064スレッドとか8スレッドもあるんだから、
そのスレッドのコンテキストを他のスレッドに譲る必要性は、
1コア1スレッドに比べると低いのです。
0438名無しさん＠お腹いっぱい。
2006/08/04(金) 02:30:51casだって、test and setと同じくバスをアトミックに使わな
ければ実現できない。だから性能面でのペナルティは同じ。
casの利点は、sparcのようなload store型アーキテクチャでも
いろいろな演算命令のアトミック版がcas命令を使って実現で
きるところ。効用は80系のlockプレフィックスに近い。
昔ながらのsparcでldstub命令やswap命令だけでアトミックな
メモリ演算を実現しようとしたら、値を保持するメモリのほか
にロック変数が必要になるが、cas命令を使うとロック変数が
いらなくなる。
0439名無しさん＠お腹いっぱい。
2006/08/04(金) 09:40:52実際には存在しない命令を前提にSMTの利点を強調されても説得力ないというか……
0440名無しさん＠お腹いっぱい。
2006/08/04(金) 12:14:46っていうか、そういう命令=ISAがあってはいけないだろうっていう意味なんだけど。
memory latencyを隠蔽するのは、CPUであってかまわないのだが、
「メモリの内容が変更されるまで待って変更後の値をロードする命令」って？
という疑問。
0441名無しさん＠お腹いっぱい。
2006/08/04(金) 12:17:41でもアトミック命令とキャッシュ・コヒーランスとは厳密には違うよね。
それにcas命令だったら、SPARCv9にあるし。
0442名無しさん＠お腹いっぱい。
2006/08/04(金) 17:06:46VMTには必要な命令でしょう。
0443名無しさん＠お腹いっぱい。
2006/08/04(金) 20:15:36当の富士通も、「SPARC64 VIは、アウトオブオーダー命令実行機能とVMTにより、
それぞれL1キャッシュミスとL2キャッシュミスによるレイテンシを隠蔽すること
ができる」といっているように、命令など使わず、VMTの利点を使ってレイテンシを
隠蔽している。（アウトオブオーダー命令実行機能は、命令じゃないよ、当然）
なんで、そんな命令が必要なのか、説明を求む。
0444名無しさん＠お腹いっぱい。
2006/08/04(金) 21:43:48ビジーウェイトはキャッシュにヒットするので、ほかのスレッドに切り替わらない。
0445名無しさん＠お腹いっぱい。
2006/08/05(土) 14:55:28> VMTでメモリのポーリングをされると台なしになるから。
> ビジーウェイトはキャッシュにヒットするので、ほかのスレッドに切り替わらない。
スピンロックで待つということは、直ちにメモリが更新されることを期待して、
他スレッドに切り替えず待つということなので、キャッシュにヒットしても、
それが直ちに更新されるのであれば、逆にスレッドに切り替えない方がいいかも
しれん。
でも、同一ロック待ちのスレッドが増加すれば、あきらかにスレッドに切り替えた方が
逆に効率がよくなるので、スピンロックの実装で、
1 メモリ値の確認
2 未更新であれば、スレッドを放棄 （スレッドコントロール命令？）
3 イベント発生時のスレッド切り替えで起きる → 1
というのもあるのかも。いずれにせよ、要件はソフト側によるもので、そうなると
「メモリの内容が変更されるまで待って変更後の値をロードする命令」というのが、
ハードにとってどれだけ効率良く実装できるかにもよるのじゃないか？
どっちにせよ、SPARC CPUの実装依存の命令になるので、SPARCのISAではなくて、
独自拡張命令にいれる類（SPARCの規約上、許される独自命令の範囲）で、一般の
SPARC ISAに命令がない、というのは、むしろ当たり前ではないのだろうか？
0446名無しさん＠お腹いっぱい。
2006/08/05(土) 16:03:23>>444が言ってるのはたとえば
cpu#0が取ったロックを、cpu#1がspinlockで開放待ちしている場合を考えると、
SMPなら普通の状況だけど、VMTで cpu#0とcpu#1が同一コアだと
spinlockが開放処理が遅れる原因になってしまう、ってことだと思うんだが
0447名無しさん＠お腹いっぱい。
2006/08/05(土) 16:22:16ここで延々やってるわけ? Niagara は VMT じゃないから、スレッドは強制的に
切り替わるでしょ?
0448名無しさん＠お腹いっぱい。
2006/08/05(土) 17:28:44っていうか、それは分かって書いているのだが。（読んでないでしょ？）
>>447
そうそう、あっても、独自命令の範疇だよね。（やりたいかどうか、ハードの
実装部隊次第っぽいけど）
0449名無しさん＠お腹いっぱい。
2006/08/05(土) 20:15:11それは当時のlinuxのスケジューラがintel のhyper threading
に対応していないくて無限ループを引き起こすというので調べた
ことがある。インテルのサイトでドキュメントを調べたた、HTの
切り替えについてきちんとした記述はなかったので、cache hit
が続いたときに永遠にthread切り替えが起こらないのか、それと
もある程度で強制的に切り替わるのか判断がつかなかった。
HTのthread切り替えの条件を正確に知っていたら教えて！
0450名無しさん＠お腹いっぱい。
2006/08/05(土) 20:47:49それって、Intelの次の↓ペーパに書いてる問題と違う？
http://www.intel.com/cd/ids/developer/asmo-na/eng/20464.htm
結論としては、マルチスレッドアプリ（カーネルの実装はいっていないが似たような
問題はあるでしょうね）では、spin lockを使わず、adaptive lock (solarisで言う)を
使えとなっているけど、最初の数ページでは、spin lock中にpauseなりで強制的に
スレッドを放棄すれば性能があがるといった、445と似たようなアドバイスがされて
いる。
0451名無しさん＠お腹いっぱい。
2006/08/05(土) 20:56:08Linuxは当時スケジューラがスレッドをCPUに割り当てる時に、
物理CPUとHyperthreadの論理CPUの区別をつけず割り当てていたので、
たとえば、２物理CPU（４論理CPU -- 2 Hyperthread/CPU）の時に、
２スレッドが１物理CPU = ２論理CPUに割り当てられ、性能が劣化したらしい。
今は、こういう場合はちゃんと２物理CPUに割り当てられるように修正されている
とのこと。
0452名無しさん＠お腹いっぱい。
2006/08/05(土) 21:57:53Intel や Linux や Windows がウンコだ、ということを証明して相対的に
Sun の評価を上げようとか、そういうこと?
0453449
2006/08/05(土) 22:36:11情報サンクスコ
そのpaperは読んでいた。お客さんのlinuxがハングするのでHTが
原因かどうか調べていたんだ。そのときlinuxカーネルのspin lock
のループに明示的にHTを離す命令(pause)の挿入位置が間違って
いたんだ。知りたかったのは、HTて明示的にpauseしなければ永久
にHTの切り替えが起こらないケースがあるかどうかってこと
0454449
2006/08/05(土) 22:38:58linuxはトラブルたびに調査の依頼がきて儲けさせてくれるので有難いです。
もっとlinuxが広まるといいのにね。
0455名無しさん＠お腹いっぱい。
2006/08/06(日) 09:03:55HTの切り替えについて気になったので、ちょこっと調べてみた。
以下の記事によると、ストールしてない限り両方交互に実行するみたい。
片方の論理CPUがbusy waitすると、CPUの性能が半分になってしまう。
が、デッドロックにはならないように思えるんだけど・・・
http://www.intel.co.jp/jp/developer/technology/itj/2002/volume06issue01/art01_hyper/p02_intro.htm
HTはSMTを採用した
http://www.intel.co.jp/jp/developer/technology/itj/2002/volume06issue01/art01_hyper/p05_front_end.htm
1クロックごとに切り替える
0456449
2006/08/06(日) 13:34:15大変サンクスコ
ちゃんと切り替わるんですね。HTが原因でlinuxがハングするというどっかの
ニュースサイトの記事が発端で、linux界ではHT性悪説が信じられているので
すが、Linuxにはガセネタがおおいなあ。
0457名無しさん＠お腹いっぱい。
2006/08/06(日) 13:43:05性能が悪いとは聞いたことがあるけど、
ハングするって聞いたこと無かった。
0458名無しさん＠お腹いっぱい。
2006/08/06(日) 14:16:360459名無しさん＠お腹いっぱい。
2006/08/06(日) 14:29:37リストラが8/3で終わっちゃったから。
0460名無しさん＠お腹いっぱい。
2006/08/06(日) 15:22:240461名無しさん＠お腹いっぱい。
2006/08/06(日) 16:28:270462名無しさん＠お腹いっぱい。
2006/08/06(日) 17:07:04Linuxの面倒をみないと生きていけないのです。
ということで言い訳を言ってみるテスト
0463名無しさん＠お腹いっぱい。
2006/08/06(日) 20:36:230464名無しさん＠お腹いっぱい。
2006/08/06(日) 22:41:58Sun Linuxって
0465名無しさん＠お腹いっぱい。
2006/08/06(日) 22:51:54コストパフォーマンスはともかく。
Linuxは使ってないからシラネ。
0466HP IBM NEC
2006/08/07(月) 07:54:490467名無しさん＠お腹いっぱい。
2006/08/07(月) 08:08:38X335のファン壊れｽｷﾞ
ラックに積めｽｷﾞですか。そうですか
0468名無しさん＠お腹いっぱい。
2006/08/07(月) 23:18:43でもSunも一番壊れやすいのはファンだからX4100とかではホットスワッパブルに
したって言ってたよね。うちのV20zのファンなんて一度も壊れたこと無いんだけど。
0469名無しさん＠お腹いっぱい。
2006/08/08(火) 01:45:200470名無しさん＠お腹いっぱい。
2006/08/08(火) 02:43:470471名無しさん＠お腹いっぱい。
2006/08/08(火) 03:19:010472名無しさん＠お腹いっぱい。
2006/08/08(火) 23:13:250473名無しさん＠お腹いっぱい。
2006/08/08(火) 23:38:00しーらない
0474名無しさん＠お腹いっぱい。
2006/08/09(水) 07:59:44ttp://blogs.sun.com/roller/page/mws#dtrace_on_macos_x_at
0475名無しさん＠お腹いっぱい。
2006/08/09(水) 11:02:49実現するにしても、もっと時間がかかるだろう。
0476名無しさん＠お腹いっぱい。
2006/08/09(水) 11:38:150477名無しさん＠お腹いっぱい。
2006/08/09(水) 11:46:00ファイルシステムという OS の基幹部分を、しかも安定して動くようにしなきゃならんとなれば…
0478名無しさん＠お腹いっぱい。
2006/08/09(水) 13:37:13モジュラーになるように設計されてる。ベル研の人達も Unix の標準のファイルシステムが
苦手な仕事をさせたければそれ用のファイルシステムを書けばいいだけ、と言ってたし。
違う OS へ持ってって、SMP もちゃんと考慮して安定させるのはまあそんなに
簡単じゃないだろうけどね。
0479名無しさん＠お腹いっぱい。
2006/08/09(水) 16:46:39まぁ、そりゃ Solaris だってファイルシステムはカーネルモジュールの一種として
実装されてるさ。でも、実際問題としてファイルシステムが安定して動かなきゃ
OS そのものも使い物になんないじゃん？ Solaris でいえば、pcfs みたいに
たまに使う程度のだったら別にたいしたことないだろうけど、（従来の）ufs の
ようにメインに使うファイルシステムだと、形式的にはカーネルモジュールではあっても
実質的には基幹部分といっても差し支えないほど重要でしょ。
ついでに、こんなのもある。
Porting ZFS to other platforms
http://opensolaris.org/os/community/zfs/porting/
ZFS filesystems
The final hurdle is the most difficult, as it will have to be largely
written from scratch using OS-specific VFS interfaces. The current ZPL code
can serve as a guideline for ideas about how to approach an implementation,
but it is extremely Solaris-specific. Some ideas (extended attributes,
NFSv4/NT ACLs) may not translate at all to some operating systems.
0480名無しさん＠お腹いっぱい。
2006/08/09(水) 20:33:44http://article.gmane.org/gmane.emacs.jdee/5046
0481名無しさん＠お腹いっぱい。
2006/08/10(木) 20:01:22移植が容易かどうかではなく利用するユーザー層の問題じゃないか？
MacOS XでZFSが必要といわれればそれほどでもないんじゃない
0482名無しさん＠お腹いっぱい。
2006/08/10(木) 21:11:26「楽天市場」システム障害・店舗の４割取引できず
ttp://www.nikkei.co.jp/news/main/20060810AT2E1000410082006.html
0483名無しさん＠お腹いっぱい。
2006/08/10(木) 22:30:300484名無しさん＠お腹いっぱい。
2006/08/11(金) 01:22:59http://www.ctc-g.co.jp/casestudy/rakuten/index.html
0485名無しさん＠お腹いっぱい。
2006/08/11(金) 01:30:44http://www.rakuten.ne.jp/gold/_sp/20060809_10/
> 今回の原因は楽天市場増強のために大型サーバーの導入を行い
> 設定ファイルの拡張作業を主に伊藤忠テクノサイエンス株式会社に
> 業務委託しておりましたが、その作業中のオペレーションミスであることが判明しました。
0486名無しさん＠お腹いっぱい。
2006/08/11(金) 01:34:46障害続いた楽天証券、基幹DBをPAからItanium 2に切り替え
http://www.itmedia.co.jp/news/articles/0511/09/news076.html
0487名無しさん＠お腹いっぱい。
2006/08/11(金) 01:35:59おおっ、CTC。ついに話題の中心へ躍り出たか?w
0488名無しさん＠お腹いっぱい。
2006/08/11(金) 01:52:57それにしても、委託先の名前出しちゃうんだ
0489名無しさん＠お腹いっぱい。
2006/08/11(金) 02:04:41CTCからもじきにおわびが出るんじゃない?
0490名無しさん＠お腹いっぱい。
2006/08/11(金) 06:57:27みると良いよ。
稼働中ディスクのディスクラベル上書き。
一時はEMCとVeritasの名前も出てたらしいけど、
もしかしたら、上の資料がリンクされていたことを指してるのかも知れない。
0491名無しさん＠お腹いっぱい。
2006/08/11(金) 12:02:12そんなもんはすぐ戻せるはず。
newfs しちゃったとしてもバックアップある（というか取ってから作業する）のが普通だろうし。
その程度のミスでなぜ延々止まるのか不思議だ。たぶん他にもしょーもないミスが複合してるな。
0492名無しさん＠お腹いっぱい。
2006/08/11(金) 15:17:24面倒っていうのが、大抵の理由。
0493名無しさん＠お腹いっぱい。
2006/08/11(金) 20:39:350494名無しさん＠お腹いっぱい。
2006/08/11(金) 22:18:43さっぱり理解していないと思われるエンジニアらしき人々が
いっぱいいてガクガクブルブル。
0495名無しさん＠お腹いっぱい。
2006/08/12(土) 03:11:28アプリ屋さんなんてそんなもんじゃないかな
ディスクラベルはともかくとして、E25K+Symmetrix+Veritasのディスク増設で
どんな作業するか想像できる人ってそんなに多くはいないんじゃね？
漏れも一瞬「VxVM使ってるのにディスクラベル書くの必要ないいじゃねーの」
って考えてしまった。
>>491
漏れは単純にディスクラベルの書き間違えじゃないかと思う。
どんだけディスク増設したのかは知らんけど、大量のディスクラベルを書く
必要があるからデバイス名の番号見間違えて稼動中のディスクラベルを
上書きしまくったんじゃないかな
■ このスレッドは過去ログ倉庫に格納されています