Changes between Version 4 and Version 5 of TipAndDoc/storage/filesystem/XFS

Timestamp:

Sep 23, 2012 10:43:49 AM (12 years ago)

Author:

mitty

Comment:

--

TipAndDoc/storage/filesystem/XFS

@@ -5 +5 @@
  > XFSって１ページ書き出すだけでもスタック3.5Kも使うのよね。カーネルスタックはページサイズx2なので8Kしかない。
  * [http://developer.cybozu.co.jp/kazuho/2010/04/mysql-and-the-x.html Kazuho@Cybozu Labs: MySQL and the XFS stack overflow problem]
+ * [https://lkml.org/lkml/2012/6/18/646 LKML: Dave Chinner: Re: XFS status update for May 2012]
+ > IOWs,the only solution that would fix the problem was to split
+ > allocations into a different stack so that we have the approximately
+ > 4k of stack space needed for the worst case XFS stack usage (double
+ > btree split requiring metadata IO) and still have enough space left
+ > for the DM/MD/SCSI stack underneath it...
 
  * [https://lkml.org/lkml/2010/4/7/110 LKML: John Berthels: PROBLEM + POSS FIX: kernel stack overflow, xfs, many disks, heavy write load, 8k stack, x86-64]
@@ -12 +18 @@
  * [https://lkml.org/lkml/2012/7/20/246 LKML: Eric Sandeen: Re: Stack overrun in 3.5.0-rc7 w/ cfq] 別の例
 
+ == CONFIG_4KSTACKS ==
+ * [http://mkosaki.blog46.fc2.com/blog-entry-1110.html 革命の日々！ さよなら CONFIG_4KSTACKS]
+ > XFSスタックオーバーフロー問題の余波でCONFIG_4KSTACKSが消えました。といっても従来の
+ > 8Kスタックとは異なりプロセス8K + IRQ 4K のハイブリッドスタックに以降することになった。
+ > 
+ > ただし、元々4Kスタックがなかった非x86アーキではスタックサイズが変わってないので
+ > 全然本質的な解決じゃない
+
+ * [https://lkml.org/lkml/2010/6/16/128 LKML: Christoph Hellwig: (PATCH) x86-32: remove CONFIG_4KSTACKS]
+  * http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=commitdiff;h=dcfa726280116dd31adad37da940f542663567d0
+
+ *  [http://d.hatena.ne.jp/naoya/20071008/1191824562 x86 Linux のメモリモデル、プロセス空間切り替え、カーネルスタック - naoyaのはてなダイアリー]
+ > Linux カーネルは割り込みスタックを用意していないという実装上の特徴がある。
+  *  これが変更になった？
+
+ == disable dirty page writeback ==
+
+ * twitter:kosaki55tea/status/183995247800500225
+ > > @kosaki55tea Linux 的には何がトレンドなの？＞ FileSystem
+ > @osada XFSのスタックの問題は解決ずみなので自分の好みで決めていい。と言いたかったのです
+ * https://twitter.com/kosaki55tea/status/167843479936970753
+ > > @kosaki55tea @m_bird @rkmathi http://mkosaki.blog46.fc2.com/blog-entry-1097.html … これですかね？
+ > @naota344 @m_bird @rkmathi ああ、それなら解決した。今はメモリ回収の延長でwritebackしない
+
+ * [http://oss.sgi.com/archives/xfs/2011-07/msg00332.html (RFC PATCH 0/5) Reduce filesystem writeback from page reclaim (again)]
+ > {{{
+ > Patch 1 disables writeback of filesystem pages from direct reclaim
+ >         entirely. Anonymous pages are still written
+ > Patch 2 disables writeback of filesystem pages from kswapd unless
+ >         the priority is raised to the point where kswapd is considered
+ >         to be in trouble.
+ > Patch 3 throttles reclaimers if too many dirty pages are being
+ >         encountered and the zones or backing devices are congested.
+ > Patch 4 invalidates dirty pages found at the end of the LRU so they
+ >         are reclaimed quickly after being written back rather than
+ >         waiting for a reclaimer to find them
+ > Patch 5 tries to prioritise inodes backing dirty pages found at the end
+ >         of the LRU.
+ > }}}
+
+ * [http://mkosaki.blog46.fc2.com/blog-entry-1110.html 革命の日々！ さよなら CONFIG_4KSTACKS]
+ > いまのXFSは別の問題があって、David Chinnerがあんまり考えずにメモリ回収時のwrite pageをdisableしちゃったからダーティーページが多いときに負荷を書けると回収可能キャッシュ残っててもOOM Killerで死ぬよ 
+  * 上のpatchでこの副作用が起きているのでは？
+
+ * [http://www.takatan.net/hiki/hiki.cgi?kswapd takatan hiki - kswapd]
+
+ === disable dirty page writebackで回避できていないように見える例 ===
+ * [https://lkml.org/lkml/2012/7/20/246 LKML: Eric Sandeen: Re: Stack overrun in 3.5.0-rc7 w/ cfq]
+  * 3.5で普通に突き破っているように見えるが、これは結局何が起きたのか
+  * パッチで回避できたはずなのではないのか
+
+ == その他 ==
+ * [https://lkml.org/lkml/2011/3/14/407 LKML: Ted Ts'o: Re: ext4 deep stack with mark_page_dirty reclaim]
+  * ext4でstack overflowした例？
+  * この例だと、symbolにext4と入っているスタックで2440byte消費しているように見える
+  * XFSだけでなく、他のFSでもstackを突き破る可能性があるのでは…？
  = misc =