patch 9.0.1411: accuracy of profiling is not optimal

Problem:    Accuracy of profiling is not optimal.
Solution:   Use CLOCK_MONOTONIC if possible. (Ernie Rael, closes #12129)
diff --git a/runtime/doc/builtin.txt b/runtime/doc/builtin.txt
index 0bdeabf..ec680be 100644
--- a/runtime/doc/builtin.txt
+++ b/runtime/doc/builtin.txt
@@ -7150,7 +7150,8 @@
 			call MyFunction()
 			echo reltimestr(reltime(start))
 <		Note that overhead for the commands will be added to the time.
-		The accuracy depends on the system.
+		The accuracy depends on the system. Use reltimefloat() for the
+		greatest accuracy which is nanoseconds on some systems.
 		Leading spaces are used to make the string align nicely.  You
 		can use split() to remove it. >
 			echo split(reltimestr(reltime(start)))[0]
@@ -10753,6 +10754,7 @@
 postscript		Compiled with PostScript file printing.
 printer			Compiled with |:hardcopy| support.
 profile			Compiled with |:profile| support.
+prof_nsec		Profile results are in nano seconds.
 python			Python 2.x interface available. |has-python|
 python_compiled		Compiled with Python 2.x interface. |has-python|
 python_dynamic		Python 2.x interface is dynamically loaded. |has-python|
diff --git a/runtime/doc/repeat.txt b/runtime/doc/repeat.txt
index c8a0f5d..054b870 100644
--- a/runtime/doc/repeat.txt
+++ b/runtime/doc/repeat.txt
@@ -1148,9 +1148,10 @@
 Profiling should give a good indication of where time is spent, but keep in
 mind there are various things that may clobber the results:
 
-- The accuracy of the time measured depends on the gettimeofday() system
-  function.  It may only be as accurate as 1/100 second, even though the times
-  are displayed in micro seconds.
+- The accuracy of the time measured depends on the gettimeofday(), or
+  clock_gettime if available, system function. The accuracy ranges from 1/100
+  second to nano seconds. With clock_gettime the times are displayed in nano
+  seconds, otherwise micro seconds.  You can use `has("prof_nsec")`.
 
 - Real elapsed time is measured, if other processes are busy they may cause
   delays at unpredictable moments.  You may want to run the profiling several