diff --git a/doc/examples/testing-tips.rst b/doc/examples/testing-tips.rst
index ca185a5a5..d201d118a 100644
--- a/doc/examples/testing-tips.rst
+++ b/doc/examples/testing-tips.rst
@@ -20,6 +20,8 @@ This may easily result in tests exhibiting unexpected, flaky, or faulty behavior
 To overcome this, you should override the detected resources by setting them in ``ray.init`` like: ``ray.init(num_cpus=2)``
 
 
+.. _local-mode-tips:
+
 Tip 2: Use ``ray.init(local_mode=True)`` if possible
 ----------------------------------------------------
 
@@ -32,6 +34,10 @@ However, there are some caveats with using this. You should not do this if:
 1. If your application depends on setting environment variables per process
 2. If your application has recursive actor calls
 3. If your remote actor/task sets any sort of process-level global variables
+4. If you use are using async actors
+
+Also note, if you are using GPUs, you must set the ``CUDA_VISIBLE_DEVICES`` environment
+variable to a comma separated list of your GPU Device IDs.
 
 
 Tip 3: Sharing the ray cluster across tests if possible
@@ -137,4 +143,4 @@ See the `Cluster Util for more details <https://github.com/ray-project/ray/blob/
 Tip 5: Be careful when running tests in parallel
 ------------------------------------------------
 
-Since Ray starts a variety of services, it is easy to trigger timeouts if too many services are started at once. Therefore, when using tools such as `pytest xdist <https://pypi.org/project/pytest-xdist/>`_ that run multiple tests in parallel, one should keep in mind that this may introduce flakiness into the test environment.
\ No newline at end of file
+Since Ray starts a variety of services, it is easy to trigger timeouts if too many services are started at once. Therefore, when using tools such as `pytest xdist <https://pypi.org/project/pytest-xdist/>`_ that run multiple tests in parallel, one should keep in mind that this may introduce flakiness into the test environment.
diff --git a/doc/source/actors.rst b/doc/source/actors.rst
index 2858febeb..3e0f43ffe 100644
--- a/doc/source/actors.rst
+++ b/doc/source/actors.rst
@@ -376,6 +376,9 @@ This allows you to retrieve the actor from any job in the Ray cluster.
 This can be useful if you cannot directly
 pass the actor handle to the task that needs it, or if you are trying to
 access an actor launched by another driver.
+Note that the actor will still be garbage-collected if no handles to it
+exist. See :ref:`actor-lifetimes` for more details.
+
 
 .. tabs::
 
@@ -415,6 +418,7 @@ access an actor launched by another driver.
       Optional<ActorHandle<Counter>> counter = Ray.getActor("some_name_in_job");
       Assert.assertTrue(counter.isPresent());
 
+.. _actor-lifetimes:
 
 Actor Lifetimes
 ---------------
@@ -469,3 +473,43 @@ Actor Pool
   .. group-tab:: Java
 
     Actor pool hasn't been implemented in Java yet.
+
+
+Actors, Workers and Resources
+-----------------------------
+What's the difference between a worker and an actor?
+
+Each "Ray worker" is a python process. 
+
+Workers are treated differently for tasks and actors. Any "Ray worker" is either 1. used to execute multiple Ray tasks or 2. is started as a dedicated Ray actor.
+
+ * Tasks: When Ray starts on a machine, a number of Ray workers will be started automatically (1 per CPU by default). They will be used to execute tasks (like a process pool). If you execute 8 tasks with `num_cpus=2`, and total number of CPUs is 16 (`ray.cluster_resources()["CPU"] == 16`), you will end up with 8 of your 16 workers idling.
+
+ * Actor: A Ray Actor is also a "Ray worker" but is instantiated at runtime (upon `actor_cls.remote()`). All of its methods will run on the same process, using the same resources (designated when defining the Actor). Note that unlike tasks, the python processes that runs Ray Actors are not reused and will be terminated when the Actor is deleted.
+
+To maximally utilize your resources, you want to maximize the time that
+your workers are working. You also want to allocate enough cluster resources 
+so that both all of your needed actors can run and any other tasks you
+define can run. This also implies that tasks are scheduled more flexibly,
+and that if you don't need the stateful part of an actor, you're mostly
+better off using tasks.
+
+
+Concurrency within an actor
+---------------------------
+
+.. tabs::
+  .. group-tab:: Python
+
+    Within a single actor process, it is possible to execute concurrent threads.
+
+    Ray offers two types of concurrency within an actor:
+
+     * :ref:`async execution <async-actors>`
+     * :ref:`threading <threaded-actors>`
+
+    See the above links for more details.
+
+  .. group-tab:: Java
+
+    Actor-level concurrency hasn't been implemented in Java yet.
diff --git a/doc/source/starting-ray.rst b/doc/source/starting-ray.rst
index 671454613..372d3f7a8 100644
--- a/doc/source/starting-ray.rst
+++ b/doc/source/starting-ray.rst
@@ -217,7 +217,7 @@ By default, Ray will parallelize its workload and run tasks on multiple processe
         -Dray.local-mode=true \
         <classname> <args>
 
-Note that some behavior such as setting global process variables may not work as expected.
+Note that there are some known issues with local mode. Please read :ref:`these tips <local-mode-tips>` for more information.
 
 .. note:: If you just want to run your Java code in local mode, you can run it without Ray or even Python installed.
 
diff --git a/doc/source/tune/user-guide.rst b/doc/source/tune/user-guide.rst
index e65acd087..0050920db 100644
--- a/doc/source/tune/user-guide.rst
+++ b/doc/source/tune/user-guide.rst
@@ -521,6 +521,8 @@ By default, Tune will run hyperparameter evaluations on multiple processes. Howe
 
 Local mode with multiple configuration evaluations will interleave computation, so it is most naturally used when running a single configuration evaluation.
 
+Note that ``local_mode`` has some known issues, so please read :ref:`these tips <local-mode-tips>` for more info.
+
 Stopping after the first failure
 --------------------------------