Avoid needless TLB flush when restarting kthreads
authorBarret Rhoden <brho@cs.berkeley.edu>
Mon, 3 Oct 2016 19:27:10 +0000 (15:27 -0400)
committerBarret Rhoden <brho@cs.berkeley.edu>
Thu, 6 Oct 2016 19:41:48 +0000 (15:41 -0400)
commit79aef241d5aa005950ebed30a31df938d586b55a
tree31ad30d87589ce1a3678856b3abe41c6608d487c
parent664b9e5222edce8dea4e374ffc1bb13c698db80e
Avoid needless TLB flush when restarting kthreads

If we're about to run on a core where our address space was arleady loaded,
we don't need to reload it.  Doing so actually triggers a TLB flush.

Regarding changing this comment:

/* In the future, we could check owning_proc. If it isn't set, we
 * could clear current and transfer the refcnt to kthread->proc. */

Although that is true, it's a bit dangerous and we'd need to measure to
know if its worth the hassle.  The intent was that if owning_proc !=
current, then this kthread is running 'detached' from its process.  This
could be a syscall that briefly woke up and went back to sleep.  We could
avoid the incref and another decref shortly (when current gets cleared in
smp_idle()->abandon_core()) by transferring the ref.

The issue is that when we clear current, we also need to load a different
page table, since it's possible that the process will be freed before this
core ends up running another page table.  So we could do this optimization,
but then we'd need to load a page table, which is a TLB flush.  Then maybe
we'd be switching back to the process again, since we don't know that the
*next* kthread to run isn't also for this process.  So it's not clear that
avoiding the atomic ops (incref/decref) and moving up the TLB flush was
worth the hassle.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
kern/src/kthread.c