From fca59bea770346cf1c1f9b0e00cb48a61b44a8f3 Mon Sep 17 00:00:00 2001
From: Harald Welte <laforge@gnumonks.org>
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

