In general, so long as it is not per-cpu list, and since there are
multiple CPUs, they may access the same list and modify it at the same
time. Then u will need the spin lock to prevent another CPU from
modifying the list. Sometimes, there are (from a recent memory bug)
cases where after calling spinlock, the CPU can be interrupted (this
scenario assumed that only one CPU is involved), and execution
continue to another path where spinlock on the SAME variable is called
again (this is in interrupt context). This will result in deadlock -
for that particular CPU. The 2nd scenario therefore will require
spin_lock_irq(), to disable the interrupt, but generally the more
relax API spin_lock() is preferred, if all the execution path where
the spin_lock on that variable is not expected to execute in interrupt
context. This is to encourage parallelism in CPU usage.
If u trace the list_move() carefully, u will ultimately come to the
spinlock api. Eg, inside shrink_active_list():
spin_lock_irq(&zone->lru_lock);=====================>this is the lock.
while (!list_empty(&l_inactive)) {
page = lru_to_page(&l_inactive);
prefetchw_prev_lru_page(page, &l_inactive, flags);
VM_BUG_ON(PageLRU(page));
SetPageLRU(page);
VM_BUG_ON(!PageActive(page));
ClearPageActive(page);
list_move(&page->lru,
&zone->inactive_list);===================>this is the list_move().
mem_cgroup_move_lists(page_get_page_cgroup(page), false);
pgmoved++;
And if u really cannot find any spin lock for the list_move(), most
likely it is a per-cpu datastructure....no locking needed as other CPU
is guaranteed NOT to touch it.
In the memory management, many times the function API can sleep, and
therefore u must unlock the spin before using the API - take note of
that too.
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ
