From fca59bea770346cf1c1f9b0e00cb48a61b44a8f3 Mon Sep 17 00:00:00 2001 From: Harald Welte Date: Sun, 25 Oct 2015 21:00:20 +0100 Subject: import of old now defunct presentation slides svn repo --- .../OLS2005/bligh/bligh-abstract.tex | 32 ++++++++++++++++++++++ 1 file changed, 32 insertions(+) create mode 100644 2005/flow-accounting-ols2005/OLS2005/bligh/bligh-abstract.tex (limited to '2005/flow-accounting-ols2005/OLS2005/bligh/bligh-abstract.tex') diff --git a/2005/flow-accounting-ols2005/OLS2005/bligh/bligh-abstract.tex b/2005/flow-accounting-ols2005/OLS2005/bligh/bligh-abstract.tex new file mode 100644 index 0000000..35fbaec --- /dev/null +++ b/2005/flow-accounting-ols2005/OLS2005/bligh/bligh-abstract.tex @@ -0,0 +1,32 @@ + +% Registration Can you handle the pressure? Making Linux +% bulletproof under load +% Martin J Bligh (mbligh@aracnet.com) + +Operating under memory pressure has been a +persistent problem for Linux customers. +Despite significant work done in the 2.6 +kernel to improve its handling of memory, it +is still easy to make the Linux kernel slow to +a crawl or lock up completely under load. + +One of the fundamental sources for memory +pressure is the filesystem pagecache usage, +along with the \ident{buffer_head} entries that +control them. Another problem area is inode +and dentry cache entries in the slab cache. +Linux struggles to keep either of these under +control. Userspace processes provide another +obvious source of memory usage, which are +partially handled by the OOM killer subsystem, +which has often been accused of making poor +decisions on which process to kill. + +This paper takes a closer look at various +scenerios causing of memory pressure and the +way VM handles it currently, what we have done +to keep the system for falling apart. This +paper also discusses the future work that +needs to be done to improve further, which may +require careful re-design of subsystems. + -- cgit v1.2.3