Re: [PATCH 03/10] mm, compaction: periodically drop lock and restore IRQs in scanners
From: Vlastimil Babka
Date: Wed Jun 11 2014 - 07:24:53 EST
On 06/11/2014 03:32 AM, Minchan Kim wrote:
>+ if (cc->mode == MIGRATE_ASYNC) {
>+ if (need_resched()) {
>+ cc->contended = COMPACT_CONTENDED_SCHED;
>+ return true;
> }
>-
>+ if (spin_is_locked(lock)) {
Why do you use spin_is_locked instead of spin_is_contended?
Because I know I have dropped the lock. AFAIK spin_is_locked() means
somebody else is holding it, which would be a contention for me if I
would want to take it back. spin_is_contended() means that somebody else
#1 is holding it AND somebody else #2 is already waiting for it.
Previously in should_release_lock() the code assumed that it was me who
holds the lock, so I check if somebody else is waiting for it, hence
spin_is_contended().
But note that the assumption was not always true when
should_release_lock() was called from compact_checklock_irqsave(). So it
was another subtle suboptimality. In async compaction when I don't have
the lock, I should be deciding if I take it based on if somebody else is
holding it. Instead it was deciding based on if somebody else #1 is
holding it and somebody else #2 is waiting.
Then there's still a chance of race between this check and call to
spin_lock_irqsave, so I could spin on the lock even if I don't want to.
Using spin_trylock_irqsave() instead is like checking spin_is_locked()
and locking, without this race.
So even though I will probably remove the spin_is_locked() check per
David's objection, the trylock will still nicely prevent waiting on the
lock in async compaction.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/