Underline importance of NUM_THREADS setting for BUFFER allocation

following augray's suggestion from #1451, and incorporating ashwinyes' comments from #1141 on the importance of NUM_THREADS even for single-threaded builds.

USAGE.md

@@ -14,6 +14,20 @@ Please build OpenBLAS with larger `NUM_THREADS`. For example, `make
 NUM_THREADS=32` or `make NUM_THREADS=64`.  In `Makefile.system`, we will set
 `MAX_CPU_NUMBER=NUM_THREADS`.
 
+Despite its name, and due to the use of memory buffers in functions like SGEMM,
+the setting of NUM_THREADS can be relevant even for a single-threaded build 
+of OpenBLAS, if such functions get called by multiple threads of a program
+that uses OpenBLAS. In some cases, the affected code may simply crash or throw 
+a segmentation fault without displaying the above warning first.
+
+Note that the number of threads used at runtime can be altered to differ from the
+value NUM_THREADS was set to at build time. At runtime, the actual number of
+threads can be set anywhere from 1 to the build's NUM_THREADS (note however,
+that this does not change the number of memory buffers that will be allocated,
+which is set at build time). The number of threads for a process can be set by
+using the mechanisms described below.
+
+
 #### How can I use OpenBLAS in multi-threaded applications?
 
 If your application is already multi-threaded, it will conflict with OpenBLAS