diff --git a/doc/guide/admin/overlays.sdf b/doc/guide/admin/overlays.sdf
index 98bbfbf63b7523dab26888610325796660173693..d49586c6362fc929d2c94e55eeabaec230121e51 100644
--- a/doc/guide/admin/overlays.sdf
+++ b/doc/guide/admin/overlays.sdf
@@ -261,7 +261,7 @@ bound to the slave will also exist on the master. If that DN does not have
 update privileges on the master, nothing will happen.
 
 You will need to restart the slave after these changes. Then, if you are using 
-{{loglevel 256}}, you can monitor an {{ldapmodify}} on the slave and the master.
+{{loglevel stats}} (256), you can monitor an {{ldapmodify}} on the slave and the master.
 
 Now start an {{ldapmodify}} on the slave and watch the logs. You should expect 
 something like:
@@ -855,6 +855,14 @@ H2: Overlay Stacking
 
 H3: Overview
 
+Overlays can be stacked, which means that more than one overlay
+can be instantiated for each database, or for the frontend.
+As a consequence, each overlay's function is called, if defined,
+when overlay execution is invoked.
+Multiple overlays are executed in reverse order (it's a stack, all in all)
+with respect to their definition in slapd.conf (5), or with respect
+to their ordering in the config database, as documented in slapd-config (5).
+
 
 H3: Example Scenarios
 
diff --git a/doc/guide/admin/troubleshooting.sdf b/doc/guide/admin/troubleshooting.sdf
index e1df5976f12bda02b570c334a9bbda96ebcf4e2a..25a6572e3e3ea1372a7b8046c604ab417d0889b9 100644
--- a/doc/guide/admin/troubleshooting.sdf
+++ b/doc/guide/admin/troubleshooting.sdf
@@ -90,7 +90,7 @@ H2: Debugging {{slapd}}(8)
 After reading through the above sections and before e-mailing the OpenLDAP lists, you
 might want to try out some of the following to track down the cause of your problems:
 
-* Loglevel 256 is generally a good first loglevel to try for getting 
+* Loglevel stats (256) is generally a good first loglevel to try for getting 
   information useful to list members on issues
 * Running {{slapd -d -1}} can often track down fairly simple issues, such as 
   missing schemas and incorrect file permissions for the {{slapd}} user to things like certs
diff --git a/doc/guide/admin/tuning.sdf b/doc/guide/admin/tuning.sdf
index 08e6db7a2a04d43fbac5dd5ebee8dea52b8b2be4..39215bf43a27f0c8ef542d337d2a6ba6e0962915 100644
--- a/doc/guide/admin/tuning.sdf
+++ b/doc/guide/admin/tuning.sdf
@@ -111,7 +111,7 @@ H2: Logging
 
 H3: What log level to use
 
-The default of {{loglevel 256}} is really the best bet. There's a corollary to 
+The default of {{loglevel stats}} (256) is really the best bet. There's a corollary to 
 this when problems *do* arise, don't try to trace them using syslog. 
 Use the debug flag instead, and capture slapd's stderr output. syslog is too 
 slow for debug tracing, and it's inherently lossy - it will throw away messages when it
@@ -131,7 +131,7 @@ and attribute {{foo}} does not have an equality index. If you see a lot of these
 messages, you should add the index. If you see one every month or so, it may
 be acceptable to ignore it.
 
-The default syslog level is 256 which logs the basic parameters of each
+The default syslog level is stats (256) which logs the basic parameters of each
 request; it usually produces 1-3 lines of output. On Solaris and systems that
 only provide synchronous syslog, you may want to turn it off completely, but
 usually you want to leave it enabled so that you'll be able to see index