Linux コンテナの歴史を追うとコンテナの仕組みがわかる / Dai Kichijoji pm2024-07-13「大吉祥寺.pm」の発表資料です。 参考となる情報にはPDF中からリンクをしていますが、資料中のリンクは Speaker Deck 上ではクリックできないので PDF をダウンロードしてご覧ください。
OSはどうやってP-coreとE-coreを使い分けているのか - Blog posts by @retrage
Alder Lake以降のIntel CPUでは、P-coreとE-coreの2種類のコアが搭載されている。 P-coreは性能重視、E-coreは省電力重視という位置づけで、OSがうまくこれらのコアを使い分けることで、消費電力と性能の両立が図られている。 ここまでの話は広く知られているが、実際にどのようにしてOSに対してコアの使い分けをさせているのかの実装レベルでの解説は (少なくとも日本語では) ほぼ存在しないようなので調べてみた。 OSから見たP-coreとE-core OSの役割の一つとしてプロセススケジューリングがあり、どのプロセスをいつどれぐらいの期間どのCPUコアで実行するかを決める。OSができるだけ効率よくプロセスをスケジューリングするためには、CPUコアの性能や消費電力の違いを考慮したスケジューリングが必要になる。そこで、Intel CPUではOSに対して次の2つの情報を
Qemuのしくみ (の一部) - VA Linux エンジニアブログ
1. 細々とした予備知識 1.1 Qemuのデバイスエミュレーション 1.2 QemuのCPUエミュレーション 1.3 Qemuのスレッド 2. 追加のI/OスレッドとAioContext 2.1 追加のI/Oスレッド 2.2 AioContext 2.3 Big Qemu Lock 3. AioContextの各種イベント処理 3.1 AioHandler 3.2 event_notifier 3.3 タイマー、Bottom half 3.5 スレッドプール 執筆者 : 箕浦 真 こういう 仕事をしていると、ときどきQemuの仕組みや内部動作をお客様に説明する必要があることがあるが、そういう時に「Qemuの〜についてはここを見てね」と言えるような文書があるといいなぁと思って自分で作ってみることにした。 1. 細々とした予備知識 1.1 Qemuのデバイスエミュレーション Qemuはコンピ
arm Mac と向き合う Web アプリケーション開発環境 - Diary
arm Mac と向き合う Web アプリケーション開発環境 しない話: Docker Desktop の課金回避 問題意識 Mac の CPU が arm になってしまった結果、以下のような問題がある JVM 系を中心に amd64 な Docker image が Mac で挙動が怪しい ネイティブ開発すっか!!となるとライブラリのバンドリングとかでおかしいことになりがち Ruby の nokogiri とか ネイティブだと古いものはわりと動かない そういう問題がなかったとして arm で開発したものを amd64 環境にデプロイするのはちょっと勇気がいる。 古い環境はアップデートせえやという話なのだが、リソース不足してるものはどうにもならず、結果として古い JVM 環境を延命させてたやつとかはまじでどうにもならなくなったりする。えてしてそういうものは皆さんの手元にあることでしょう。
CPU律速なRuby/Pythonコードはデフォルト設定のdocker上で遅くなる - まめめも
English version 要約 dockerはデフォルトでセキュリティ機構（Spectre脆弱性の対策）を有効にします。この影響で、RubyやPythonのようなインタプリタは速度が劣化します。特にCPU律速なプログラムで顕著に遅くなります（実行時間が倍くらいになることがあります）。 現象 Rubyで1億回ループするコードを、直接ホスト上で実行する場合と、docker上で実行する場合で実行時間を比較してみます。 直接ホスト上で実行した場合： $ ruby -ve 't = Time.now; i=0;while i<100_000_000;i+=1;end; puts "#{ Time.now - t } sec"' ruby 2.7.1p83 (2020-03-31 revision a0c7c23c9c) [x86_64-linux] 1.321703922 sec docker
サーバ室の空調を止めるとこうなる - treedown’s Report
サーバルームのエアコンを止めるとこうなりますよ、という内容を実際に遭った昔話の形でご報告します。 節電のためにサーバ室のエアコンを停止しようとする人にも読んでもらいたい体験談です。 最近、猛暑も収まり、過ごしやすい気温になってきました。 が、サーバ室のサーバ達は外気が何℃であれ、動作範囲内の稼働環境でなければボイコットを招くことになります。 あの日も今日と同じく土曜日でした。 むかーし昔、10年くらいちょっとした昔。 ある日の土曜日夕方、会社から携帯に入電。 「サーバが全停止しているそうです。すぐ来てください。」 えぇっ！どしたの？ 「最初はサーバ室が火事だ、って騒ぎになっていたんですけど、それは誤報で、どうやらエアコンが止まったせいでサーバが全停止したらしいんです。」 うゎぁ…。 急いで電車に乗って最寄駅からダッシュすること15分、会社に到着すると緊急事態で駆けつけた部員と何人かの休日出
電源を切っても消えないメモリとの付き合い方
メモリのように書けて永続化される次世代ストレージデバイスNVDIMMの扱い方を解説します これは2019年10月19日に行われる予定だった カーネル／VM探検隊＠北陸 5回目(台風の影響で中止) での発表資料です サンプルコード: https://github.com/Fadis/kernelvm_20191019_samples
x86上のLinuxとFreeBSDにおいて、メモリキャッシュを無効にするカーネルモジュールを書いた話 - alphakai’s tech blog
どうも、前回の記事が思っていたよりも反響があり、Blogを書くモチベーションが高まり、また記事を書くことにします。 ↑とか書いたんですが、このへんまで書いて50日くらい記事を書くのを放置していたので、ちゃっちゃと書き上げることにします。 今回はx86なCPUに存在するControl Registerのうち、CR0に存在するCache Disableフラグを操作するカーネルモジュールをLinux、FreeBSDのそれぞれ向けに作ったのでそれについて記述します。 それでは、続きからどうぞ。 はじめに、作成したカーネルモジュールのリポジトリへのリンクを掲載します。 Linux版のカーネルモジュール(procfsとして実装) cr0cd FreeBSD版のカーネルモジュール(キャラクタデバイスとして実装)cr0cd_fbsd そもそもこれはなに 一言で言うと、メモリのキャッシュ(L1, L2, L
AMDのZen 2でRDRANDが-1を返すので最近のGNU/Linuxがブートできない問題
AMDのZen 2アーキテクチャの新製品が発売されて沸き立っているが悲しいお知らせがある。最近のGNU/Linuxディストロはブートしない。例えばUbuntu 19.04はブートしない。 理由は、ハードウェア乱数を返す命令、RDRANDに不具合があり、常に-1を返すのだという。このため、rdrandを直接使っているsystemdが失敗し、結果としてブートできなくなる。 AMDによればこの問題はBIOSアップデートで修正可能であるという。しかしこれはとても怪しい陰謀論を考えたくなる。なぜRDRANDが常に-1を返すような不具合が未然に発覚せずに製品リリースまでこぎつけてしまったのか。なぜファームウェアのアップデートで修正可能なのか。まさかバックドアなのではないか。 陰謀論はともかくとして、もう一つの問題は、なぜsystemdはRDRANDを直接使っているのかということだ。Linuxカーネルの
#42 – kvm: the Linux Virtual Machine Monitor
KVM など Linux の仮想化技術について森田が話します。感想などはハッシュタグ #misreading か hello@misreading.chat にお寄せください。 Virtual Machines: Versatile Platforms for Systems and Processes (The Morgan Kaufmann Series in Computer Architecture and Design): Jim Smith, Ravi Nair: 9781558609105: Amazon.com: Books QEMU, a Fast and Portable Dynamic Translator Tiny Code Generator TCC : Tiny C Compiler Xen and the Art of Virtualization x86 v
新機能 – EC2 A1インスタンス – ARMベースのAWS Gravitonプロセッサーを搭載 | Amazon Web Services ブログ
Amazon Web Services ブログ 新機能 – EC2 A1インスタンス – ARMベースのAWS Gravitonプロセッサーを搭載 今年の初めに私がAWS Nitroシステムについてご紹介したとき、この数ヶ月のうちに、AWS Nitroによってこれまでよりも速く新しいインスタンスタイプを提供できるようになります、とお約束したのを覚えているでしょうか。私たちはこの言葉どおり、より多くのメモリを搭載したR5とR5dインスタンス、高クロック周波数で動作するz1dインスタンス、バースト可能なt3インスタンス、12TiBものメモリを選択可能なハイメモリインスタンス、それからAMDプロセッサベースのM5aとR5aインスタンスを提供してきました。EC2インスタンスをホストするハードウェアの能力を最大限に活用しながら、私たちはAWS Nitroシステムを構成する専用のハードウェアと軽量ハイ
13. 自作アセンブラ、リンカの最適化、トリッキーなビット操作の楽しさ、外資系IT企業のコーディング面接対策
hikaliumの自作アセンブラや自作言語、データ構造やトリッキーなビット操作を使ったアルゴリズム、リンカの最適化などについて話をしました。出演者: hikalium (@hikalium)、Rui Ueyama (@rui314) https://turingcomplete.fm/13 ハッシュタグは#tcfmです。 TCFMはサポーターの投げ銭によって収益を上げています。このコンテンツに課金してもいいよという方はぜひクリエイター支援サイトPatreonから登録してご協力ください。 イントロ (0:00) asmium — hikalium自作アセンブラ (1:20) Mach-Oオブジェクトファイルを自作アセンブラから出力するには (6:27) AppleがCPUをIntelからスイッチするという噂 (8:21) ラベルの後方参照がオブジェクトファイル内で解決されていない？ (11:
CPUの脆弱性 MeltdownとSpectreについてまとめてみた - piyolog
2018年1月3日にCPUに関連する3つの脆弱性情報が公開されました。報告者によるとこれらの脆弱性はMeltdown、Spectreと呼称されています。ここでは関連情報をまとめます。 脆弱性の概要 報告者が脆弱性情報を次の専用サイトで公開した。 Meltdown and Spectre (またはこちら) 3つの脆弱性の概要をまとめると次の通り。 脆弱性の名称 Meltdown Spectre CVE CVE-2017-5754（Rogue data cache load） CVE-2017-5753（Bounds check bypass） CVE-2017-5715（Branch target injection） 影響を受けるCPU Intel Intel、AMD、ARM CVSSv3 基本値 4.7(JPCERT/CC) 5.6(NIST) ←に同じ PoC 報告者非公開 論文中にx
乱数生成器とゲームと諜報活動の話｜Rui Ueyama
ゲームなどを作っているとランダムさが必要になることがあるけど、コンピュータは基本的に毎回全く同じように動くので、乱数を作り出すのはそう簡単なことではない。Wi-FiやHTTPSなどの暗号は乱数のランダムさに本質的に依存しているので、高品質な乱数生成は世の中的にも重要な話題である。ここでは乱数生成について話をしてみよう。 ゲームではイベントがプレイヤーに予測不可能であればよいだけなので、真の乱数列ではなく擬似乱数列というものを使うことが多い。擬似乱数列は人間にはランダムにみえるけど、実際は何らかの数式によって順番に生成されているだけの数の列で、初期値を毎回違うものにしておくと、人間には毎回違う数列が生成されるようにみえる。初期値には現在時刻を使うことが多い。現在時刻は普通の用途では毎回違うからだ。 昔のゲーム機は現在時刻の設定がなかったので、ファミコンなどでは、起動してからの経過時間を疑似乱
OSX以前のMacにおけるUNIX - 仮想と現実
スティーブ・ジョブズが帰ってきてMacOS Xが登場するずっと前から、MacでUNIXまたはUNIXっぽいものを動かす試みはあった。 A/UX Apple純正のUNIXである。System/V系にBSDの要素も足した結構しっかりしたシステムだった。一見MacOSの上にUNIX要素を足したように見えるが逆で、UNIXシステムの上にMacエミュレーション層を置いていた。ファイルシステムもMacのHFSではなくUFSで、その上でリソースフォークやメタデータを扱うために、AppleDoubleという方式が用いられた。 68kMac用で、FPUとPMMUを必要としたため、動かない機種も多かったらしい。大学などで使われた。 Mac MiNT Atari ST純正OS、TOSをマルチユーザーマルチタスクにしたMiNTというUNIX風OSを68kMacに移植したもの。Macの上で一つのアプリケーションとし
C++11のスレッド、アフィニティ、ハイパースレッディング | POSTD
背景と導入 何十年もの間、CやC++の標準規格は、マルチスレッディングや並行処理を「その標準の範囲を超えたもの」として扱ってきました。標準規格の目的である”抽象機械”の力が及ばない、”対象依存”という影の世界においてです。メーリングリストやニュースグループの質問には並行処理に関するものが山ほど寄せられましたが、それらにすぐに突き返された回答は「C++はスレッドには関知しません」という何とも冷淡なものでした。この件によって当時のことを思い出す人々は、今後も絶えないでしょう。 しかしC++11の登場で、そんな状況に終止符が打たれたのです。C++標準化委員会は、時代の流れに乗らないと、この先C言語が取り残されてしまうと悟ったのでしょう。彼らはスレッドや同期メカニズム、アトミック操作、メモリモデルなどの存在に、ようやく気付いたわけです。そして標準規格として、C++コンパイラやライブラリのベンダーに
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
トラブルシューティングから Linux カーネルに潜り込む
【特集】 Windows 11をMacで使う方法。vTPMが標準ONになった「Parallels Desktop 17.1」で、どのアプリが動くのか検証してみた
龍芯3号で動作するWindowsそっくりなLinux OS「中標麒麟V7.0」
Qualcommチップセットの脆弱性「QuadRooter」、9億台以上のAndroid端末に影響 
