From 8536db4580e8c93ea34d72e35ba4c328acb6d69a Mon Sep 17 00:00:00 2001
From: Vladislav Bolkhovitin <vst@vlnb.net>
Date: Mon, 6 Sep 2010 14:07:09 +0000
Subject: [PATCH] Docs update

git-svn-id: http://svn.code.sf.net/p/scst/svn/trunk@2059 d57e44dd-8a1f-0410-8b47-8ef2f437770f
---
 scst_local/README | 28 ++++++++++++++++++++++++++--
 1 file changed, 26 insertions(+), 2 deletions(-)

diff --git a/scst_local/README b/scst_local/README
index dc2fa7b75..8493b5d62 100644
--- a/scst_local/README
+++ b/scst_local/README
@@ -1,4 +1,4 @@
-SCST Debug ...
+SCST Local ...
 Richard Sharpe, 30-Nov-2008
 
 This is the SCST Local driver. Its function is to allow you to access devices
@@ -66,7 +66,31 @@ The code still has bugs, so if you encounter any, email me the fixes at:
 
 I am thinking of renaming this to something more interesting.
 
-6. Change log
+
+Limitations
+===========
+
+Swapping on scst_local's devices and using a writable mmap over a file
+on them are not supported due to possible OOM deadlock in the Linux
+memory/cache manager. See SCST README for more details.
+
+
+Note on performance
+===================
+
+Although this driver implemented in the most performance effective way,
+including zero-copy passing data between SCSI/block subsystems and SCST,
+in many cases it is NOT suited to measure performance as a NULL link.
+For example, it is not suited for max IOPS measurements. This is because
+for such cases not performance of the link between the target and
+initiator is the bottleneck, but CPU or memory speed on the target or
+initiator. For scst_local you have both initiator and target on the same
+system, which means each your initiator and target are much less
+CPU/memory powerful.
+
+
+Change log
+==========
 
 V0.1 24-Sep-2008 (Hyderabad) Initial coding, pretty chatty and messy,
                              but worked.