Merge branch 'sverk/ets-write_concurrency-locks'

* sverk/ets-write_concurrency-locks:
  erts,stdlib: Increase number of locks for write_concurrency

OTP-10787

2 files changed, 8 insertions, 4 deletions

diff --git a/erts/emulator/beam/erl_db_hash.h b/erts/emulator/beam/erl_db_hash.h
index cddd8dfadd..73c4078fc5 100644
--- a/erts/emulator/beam/erl_db_hash.h
+++ b/erts/emulator/beam/erl_db_hash.h
@@ -33,7 +33,7 @@ typedef struct hash_db_term {
     DbTerm dbterm;         /* The actual term */
 } HashDbTerm;
 
-#define DB_HASH_LOCK_CNT 16
+#define DB_HASH_LOCK_CNT 64
 typedef struct db_table_hash_fine_locks {
     union {
 	erts_smp_rwmtx_t lck;
diff --git a/lib/stdlib/doc/src/ets.xml b/lib/stdlib/doc/src/ets.xml
index abaf64fb91..44c050a0d3 100644
--- a/lib/stdlib/doc/src/ets.xml
+++ b/lib/stdlib/doc/src/ets.xml
@@ -932,7 +932,8 @@ ets:select(Table,MatchSpec),</code>
               If set to <c>true</c>, the table is optimized towards concurrent
               write access. Different objects of the same table can be mutated
               (and read) by concurrent processes. This is achieved to some degree
-              at the expense of sequential access and concurrent reader performance.
+              at the expense of memory consumption and the performance of
+	      sequential access and concurrent reading.
 	      The <c>write_concurrency</c> option can be combined with the
 	      <seealso marker="#new_2_read_concurrency">read_concurrency</seealso>
 	      option. You typically want to combine these when large concurrent
@@ -944,8 +945,11 @@ ets:select(Table,MatchSpec),</code>
               <seealso marker="#concurrency">atomicy and isolation</seealso>.
               Functions that makes such promises over several objects (like
               <c>insert/2</c>) will gain less (or nothing) from this option.</p>
-             <p>Table type <c>ordered_set</c> is not affected by this option in current
-              implementation.</p>
+             <p>In current implementation, table type <c>ordered_set</c> is not
+	     affected by this option. Also, the memory consumption inflicted by
+	     both <c>write_concurrency</c> and <c>read_concurrency</c> is a
+	     constant overhead per table. This overhead can be especially large
+	     when both options are combined.</p>
           </item>
           <item>
             <marker id="new_2_read_concurrency"></marker>