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つの情報を
Google、NVIDIA、Qualcomm、インテルらが、RISC-V用オープンソース開発を加速させる組織「RISC-V Software Ecosystem」（RISE）プロジェクトを立ち上げ
Google、NVIDIA、Qualcomm、インテルらが、RISC-V用オープンソース開発を加速させる組織「RISC-V Software Ecosystem」（RISE）プロジェクトを立ち上げ RISC-V（リスクファイブ）プロセッサ対応のオープンソース開発を加速させる組織「RISC-V Software Ecosystem」（RISE）プロジェクトが、Linux Foundation Europeをホストとし、Google、NVIDIA、Qualcomm、インテルを始めとする13社がボードメンバーとなってスタートしました。 もともとRISC-Vはカリフォルニア大学バークレイ校のコンピュータサイエンス科が開始した、新しいプロセッサ命令セットを開発するためのプロジェクトです。創立メンバーにはRISCプロセッサの基礎を築いた計算機科学者のデイビッド・パターソン博士らがおり、当初は教育に使う
サーバ室の空調を止めるとこうなる - treedown’s Report
サーバルームのエアコンを止めるとこうなりますよ、という内容を実際に遭った昔話の形でご報告します。 節電のためにサーバ室のエアコンを停止しようとする人にも読んでもらいたい体験談です。 最近、猛暑も収まり、過ごしやすい気温になってきました。 が、サーバ室のサーバ達は外気が何℃であれ、動作範囲内の稼働環境でなければボイコットを招くことになります。 あの日も今日と同じく土曜日でした。 むかーし昔、10年くらいちょっとした昔。 ある日の土曜日夕方、会社から携帯に入電。 「サーバが全停止しているそうです。すぐ来てください。」 えぇっ！どしたの？ 「最初はサーバ室が火事だ、って騒ぎになっていたんですけど、それは誤報で、どうやらエアコンが止まったせいでサーバが全停止したらしいんです。」 うゎぁ…。 急いで電車に乗って最寄駅からダッシュすること15分、会社に到着すると緊急事態で駆けつけた部員と何人かの休日出
Cの可変長引数とABIの奇妙な関係 - Qiita
printf に関する以下のツイートが流行っていました。 上のツイートでは割とあっさり説明されていますが、amd64 SysV ABIでこの現象が起こる理由にはもっと深遠なものがあると思うので、可変長引数とからめて説明してみたいと思います。 前提条件として「ABI」「可変長引数」「non-prototyped関数」の知識が必要なのでそこから説明します ABIとは ABI (Application Binary Interface) とは、機械語レベルでのインターフェースのことです。 機械語そのもののルールはISA (Instruction Set Architecture) によって規定されていますが、たとえばC言語の「関数呼び出し」などの概念を機械語でどのように表現するかについては規定していません。そのルールを定めたのがABIです。したがって、ISAとABIはおよそ1対多の関係にあります
Rustこそがシステムプログラミングの未来（で、C言語はもはやアセンブリ相当）なら、Rustで書かれたドライバのコードをLinuxカーネルは受け入れるべきなのか？ - YAMDAS現更新履歴
Intel の主席エンジニアの Josh Triplett の Open Source Technology Summit 2019 での講演 Intel and Rust: the Future of Systems Programming を取り上げ、Rust こそがシステムプログラミングの未来であり、C 言語はもはやかつてのアセンブリ言語である。つまり、未だに OS などのシステムプログラミングの大部分で使われる C 言語は Rust に置き換えられるのではないかと見る記事である。 「Cを愛して…」という文章をワタシが訳したのももはや10年以上前、C が他言語に置き換えられる未来が遂に来るのかと遠い目になってしまう。もっともワタシ自身、4年近く C 言語でコーディングしてないんだよね……。 でも、本当にそうなるのだろうか？ 手近なシステムプログラミングの現場である 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
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
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の上で一つのアプリケーションとし
なぜDockerとCoreOSの決裂は予測できたか | POSTD
「私が滑っていく先はパックが向かう所であり、パックがあった所ではない」－Wayne Gretzky CoreOSとDockerの間で 最近 、 騒動 がありました。DockerはCoreOSのクラスタ管理の領域に入り込むために構築している製品の範囲を広げています。それにより、CoreOSがDockerと競合する独自のコンテナランタイム Rocket を発表したのです。そういった動きは、Clayton Christensenの『 Law of Conservation of Modularity 』を読んでいれば十分に予測できるものでした。 我々がコモディティ化に関する研究から洞察したのは、コモディティ化がバリューチェーンのどこかで進んでいる時はいつも、脱コモディティ化という逆のプロセスがバリューチェーンの別のどこかで進んでいるということです。（中略）この2つのプロセスが相互関係にあるという
sched_clock() overflow after 208.5 days in Linux Kernel
えーっと、久しぶりに Linux Kernel にダメダメなバグが発見されて、よりにもよってうちの製品も影響を受けたので、ここに詳細を書くことにした。 つーか。新しい Kernel を使うなら皆で使おうよ。なんだよその「1つだけ」影響を受けて残りは「影響も受けないぐらい古い」ってのは… 概要 大雑把に 208.5日連続運転した Linux Kernel が突如として reboot する。 実機でなおかつ Time Stamp Counter を内包している必要があるので、Pentium4以降のプロセッサ(が、それはようするに今ある Intel 系CPU全部)か、その互換CPUである必要がある。32bit モード、64bit モードの区別はない。 逆に VMware や Xen など、仮想マシン上で動いている kernel に影響はない。これはそもそもバグを内包したルーチンを、仮想マシンで動
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Intel、指先に乗る極小x86コンピュータ「Edison」を正式発表 ～日本でも10月発売