タグ

関連タグで絞り込む (9)

タグの絞り込みを解除

kernelに関するn314のブックマーク (14)

  • Huge Page まとめ

    You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

    Huge Page まとめ

  • マイクロカーネルとL4について (Yabaitech.tokyo, Writing a (micro)kernel in Rust in 12 days より) - 豆腐の豆腐和え


    怒田さん*1のこの記事、﹁CとRustで一から作るマイクロカーネルOS﹂のおかげで、マイクロカーネルとRustが今ホットです。そこで、技術書典6, 7に出展したYabaitech.tokyoにて連載している、"Writing a (micro)kernel in Rust in 12 days"から、マイクロカーネルとL4についての話を書いた"1日目"の記事の一部冒頭を、いい機会なので再編集してご紹介します。﹁マイクロカーネルってタネンバウム教授とリーナスの論争のあれだよね？﹂とか、﹁L4ってなに？﹂って方に読んでいただいて、L4ファミリーとマイクロカーネルについて簡単にご紹介できればなと思います。 ちなみに抜粋元の上述の記事は、僕が怒田さんと同じようにRustでマイクロカーネルを書いてみよう、という趣旨の企画です。なので、Yabaitech.tokyoの方もよろしくお願いします！ただし、
    マイクロカーネルとL4について (Yabaitech.tokyo, Writing a (micro)kernel in Rust in 12 days より) - 豆腐の豆腐和え
    n314
    n314 2019/12/16
    前にWikipediaで、今の商用OSはだいたいハイブリッドカーネル、みたいな説明を読んだけど、いまいちピンときてない。
    リンク

  • ファイルシステムサイズの拡張時にデータベースアクセスがスローダウンする問題の解決 - Cybozu Inside Out | サイボウズエンジニアのブログ


    はじめに こんにちは、技術顧問のsatです。 サイボウズでは、ファイルシステムサイズ拡張時にデータベースアクセスがスローダウンするという問題に長年悩まされてきました。本記事では運用本部の藤田と深谷がこの問題を解決した流れについて報告いたします。問題を解決するために2人はLinuxカーネルを修正しました。修正は社内に閉じたものではなく、執筆当時の最新 Linuxカーネルであるv4.17にマージされています。 問題 以下の操作の後にデータベースへのアクセスが一時的にスローダウンする ブロックデバイスのサイズを拡張する 上記デバイス上にあるファイルシステムのサイズを拡張する 原因 linuxカーネルはブロックデバイスのサイズ変更(縮小および拡張)時に、当該デバイス上にあるファイルシステムのページキャッシュ(後述)を無効化する*1 解決方法 ブロックデバイスのサイズ拡張時にはページキャッシュを無効
    ファイルシステムサイズの拡張時にデータベースアクセスがスローダウンする問題の解決 - Cybozu Inside Out | サイボウズエンジニアのブログ
    n314
    n314 2018/06/28
    問題解決能力が高い例
    リンク

  • Linuxのloadavgが約7時間ごとに上昇する現象の原因 - Mackerel お知らせ #mackerelio


    Mackerelチームのエンジニアのid:itchynyです。 ﹁mackerel-agentを入れるとloadavgが7時間ごとに上昇する﹂ 先日、このような問い合わせを複数のお客さまから受けました。私も実験してみたところ、確かに再現しました。EC2 t2.microにmackerel-agentを入れて簡単なログ監視とプロセス監視を設定し、数日放置しました。 確かに、約7時間ごとにloadavgが上昇しています。この周期のcronの設定はしておらず、またmackerel-agent内部でも7時間ごとに行う処理はありません。しかし、プラグインを多く入れるほどloadavgのピーク値も上がります。 本エントリーでは、この現象の原因について説明します。 loadavgが上昇する原因を調べるには、まずloadavg自体がどう計算されているかを知る必要があります。 まずは、Linuxがloada
    Linuxのloadavgが約7時間ごとに上昇する現象の原因 - Mackerel お知らせ #mackerelio
    n314
    n314 2018/06/13
    すごいけど、実際には計算とカーネル見る前に load average "7 hours" とかで検索してから調べてそう。
    リンク

  • システムコールを経由する生のLinuxスレッド | POSTD


    Linuxのスレッドは、洗練された美しい設計です。スレッドは仮想アドレス空間とファイルディスクリプタテーブルを共有するプロセスに過ぎません。プロセスによって生成されたスレッドは、メイン”スレッドの”親プロセスに追加された子プロセスです。これらは同じプロセス管理のシステムコールを通して処理されるので、スレッドに関するシステムコールのセットを分ける必要性を取り除きます。これはファイルディスクリプタと同様に洗練された方法です。 一般的に、UNIX系のシステムではfork()を使ってプロセスを生成します。新しいプロセスは、オリジナルのコピーとして独自のアドレス空間とファイルディスクリプタテーブルを取得します。︵Linuxではコピーオンライトを使用して、この部分を効率的に処理します。︶しかし、これは非常に高度なスレッドの生成方法なので、Linuxでは別の clone() システムコールを使用します。
    システムコールを経由する生のLinuxスレッド | POSTD
    n314
    n314 2015/07/10
    glibcなどのラッパー関数使わずにプログラム書くっていうのも一度はやっておきたいね。
    リンク

  • 共有メモリ設定パラメータのshmallとshmmax - shibainu55日記

    PostgreSQLなどをはじめ、DBMSを動かすサーバでは一般的にカーネルパラメータshmmax、shmallのパラメータの変更が行われる。この設定変更に関する情報はWebの色んなサイトにあるが、一部のサイトでは誤った記載が間々あるように思う。というのも、「shmallとshmmaxの設定値を同じ値に設定するんだ」、という説明は正しくない。一部のサイトでは、shmallの値をバイト数で指定しようとしているように見受けられる。 Linuxカーネルのソース(linux-2.6.18/include/linux/shm.hの17行目〜)を読むと、こんなコメントが。shmallについては、バイト数ではなくページ数を設定する。 #define SHMMAX 0x2000000 /* max shared seg size (bytes) */ #define SHMMIN 1 /* min sha

    共有メモリ設定パラメータのshmallとshmmax - shibainu55日記
    n314
    n314 2015/03/27
     今PostgreSQL9.1のマニュアルみたけどそっちも間違ってるのか。確かにshmallの初期値はshmmax/16だった。カーネル変わったら毎回変更前に初期値を調べた方が良さそうね。  

    ●linux
    ●kernel
      
    リンク

  • Linuxのしくみを学ぶ - プロセス管理とスケジューリング


    ﹁Linuxのしくみを学ぶ - プロセス管理とスケジューリング﹂公開ページ こちらのページはSoftware Design誌 2009年12月号の記事﹁Linuxのしくみを学ぶ - プロセス管理とスケジューリング﹂の公開ページです。 ﹁ハイパーバイザの作り方﹂も公開中ですので、こちらも是非ご覧ください。 公開中の記事 HTML PDF ePub mobi Kindle 原稿データ 全ての原稿データはgithub上で公開されています。 Pull RequestやIssuesを通じて文章の誤り訂正や解説の追記、各フォーマットの表示の改善などのコントリビューションを受け付けています。 改善された記事は随時このページにアップロードしていきます。 記事に関するご質問 記事を読んで何かわからなかった点があったり、疑問に思ったことがあれば以下の連絡先に問い合わせてください。 Twitter: @syuu

  • Linuxカーネルハックに興味があるけど特にネタが無いんだよな〜って人向けの小ネタ - φ(・・*)ゞ ｳｰﾝ　カーネルとか弄ったりのメモ


    Linuxカーネルに興味があるんだけど特に作りたいものってないんだよなーなんて割とあると思う訳です。俺とか。。。 まあ、kernelnewbiesのメーリングリストでもよく見る話題かと思います。この辺なんかもそうですね。 で、そんな時にオススメできるのがkmemleak。カーネルに組み込まれたメモリーリーク検出ツールです。 使い方は至って簡単でカーネルのコンフィグレーションにあるKernel memory leak detectorを有効にしたカーネルを普通に使えばOK。カーネルはメインラインのrcでもtipでもlinux-nextでも何でも良いと思います。 設定の場所はKernel Hacking ->Memory Debugging -> Kernel memory leak detectorにチェックをするのと、 その下のMaximum kmemleak earlylog ent
    Linuxカーネルハックに興味があるけど特にネタが無いんだよな〜って人向けの小ネタ - φ(・・*)ゞ ｳｰﾝ　カーネルとか弄ったりのメモ

  • Linux Torvalds、最近のCPUのPage Faultのコストにご不満の様子

    Linus Torvalds - Google+ - One of the things I end up doing is do a lot of performance… Linus Torvaldsが、最近のIntelのCPUは、通常以外の処理のコスト、つまりPage faultのコストが上がっているので、問題であるとしている。 俺はよくカーネルコードのパフォーマンスプロファイリングをやる。特に、VMとかファイルシステム周りに対してだ。 俺がよくやるのは、「うまくいってるとき」に対する計測だ。つまり、だいたいほぼ完璧にキャッシュされてる状況だな。というのも、俺はもちろんIOのことは気にかけているが、俺の個人的なワークロードはたいてい、うまくキャッシュされてるからだ。たとえば、俺にとってよくあるロードは、pullした後のフルカーネルビルドだ。これにどのくらいの時間がかかるかが問題になる

  • Linux Storage Filesystem/MM Summit 2014からの便り

    Linux Storage Filesystem/MM Summit 2014からの便り：Linux Kernel Watch（1/2 ページ） お久しぶりです、Linux Kernel Watchが帰ってきました。3月に行われた「Linux Storage Filesystem/MM Summit 2014」の主なトピックを紹介します。 皆さん、お久しぶりです。私は今ボストンで、米レッドハット常駐という立場でRed Hat Enterprise Linux（RHEL）開発に携わっています。 今回はサンフランシスコ近郊のナパバレーで2014年3月24～25日に行われた「Linux Storage Filesystem/MM Summit 2014」（以下LSF/MM）の中から面白かったトピックをピックアップしてお届けしたいと思います。 LSF/MMはLinux Foundation主催で行

    Linux Storage Filesystem/MM Summit 2014からの便り

  • 新208.5日問題 - Systems with Intel® Xeon® Processor E5 hung after upgrade of Red Hat Enterprise Linux 6

    Linux の連続稼働時間が 208.5 日を過ぎた段階で突如 Kernel Panic を引き起こすという過激な挙動で2011年の年の瀬に話題となった "旧208.5日問題" ですが、あれから二年が経った今、Linux Kernel 内の bug と Intel Xeon CPU の bug の合わせ技により再度類似の不具合が発生することが分かっています。 旧 208.5 日問題の発生原理に関しては以下の blog が参考になります。 okkyの銀河制圧奇譚 : sched_clock() overflow after 208.5 days in Linux Kernel 追記(2014/1/4) 新208.5日問題の簡易チェックツールを作成しました。よろしければお使い下さい。 tsc_checker - 新208.5日問題簡易チェックツール また、Linux Kernel における時間

  • JF: Linux Kernel 3.x/2.6 Documentation: CodingStyle

    Linux カーネル コーディング規約 [プレインテキスト版] 原著作者: Linus Torvalds <torvalds at osdl dot org> 翻訳者: Ken Iwamoto <iwamoto dot kn at ncos dot nec dot co dot jp> Toshikazu Nakayama <nakayama dot ts at ncos dot nec dot co dot jp> Nobuo Yoshida <yoshida dot nb at ncos dot nec dot co dot jp> バージョン: 2.6.24 翻訳日時: 2008/03/26 ================================== これは、 linux-2.6.24/Documentation/CodingStyle の和訳 です。 翻訳団体： JF プ

  • Ubuntuのカーネル再構築 - adsaria mood

    以前、Redhat系のCentOSのカーネルを再構築したが（「CentOSのカーネル再構築」）、今回はUbuntu（Debian系）の再構築を試みた。 カーネル本体はディストリビューションとは独立しているので基本的なやり方は同じだが、Debianではカーネルの再構築用のユーティリティ（スクリプト等）を提供しているので、それらを使って簡単に構築できる。 次のような手順となる。 環境の整備（開発環境パッケージの追加） ソースコード・パッケージのダウンロード ソースコードの展開 カーネルのコンパイル カーネルのインストール 本来は3と4の間にカーネル構成の設定があるが、今回は先ず現在動いているカーネルと同じ構成のものを作ることを目的としたので省略した。 ■　環境の整備 Ubuntuはインストールしたての状態でコンパイルの環境が十分ではないためまず、一応、コンパイラの環境を整える。 root@ub

    Ubuntuのカーネル再構築 - adsaria mood

  • Alternative To The "200 Lines Kernel Patch That Does Wonders" Which You Can Use Right Away

    Phoronix recently published an article regarding a ~200 lines Linux Kernel patch that improves responsiveness under system strain. Well, Lennart Poettering, a RedHat developer replied to Linus Torvalds on a maling list with an alternative to this patch that does the same thing yet all you have to do is run 2 commands and paste 4 lines in your ~/.bashrc file. I know it sounds unbelievable, but appa

  • 1

お知らせ

もっと読む

公式Twitter

  • @HatenaBookmark

    リリース、障害情報などのサービスのお知らせ

  • @hatebu

    最新の人気エントリーの配信

はてなブックマーク

公式Twitter

はてなのサービス

  • App Storeからダウンロード
  • Google Playで手に入れよう
Copyright © 2005-2024 Hatena. All Rights Reserved.