e43d3f21c5
Usually, when we call cond_resched(), we want the write lock to be released and then reacquired once we return from scheduling. Not only does it follow the previous bkl based locking scheme, but it also let other waiters to get the lock. But if we aren't going to reschedule(), such as in !TIF_NEED_RESCHED case, it's useless to release the lock. Worse, if we release and reacquire the lock whereas it is not needed, we create useless contentions. Also if someone takes the lock while we are modifying or reading the tree, there are good chances we'll have to retry our operation, eg if the block we were seeeking has moved. So this patch introduces a helper which only unlock the write lock if we are going to schedule. [ Impact: prepare to inject less lock contention and less tree operation attempts ] Reported-by: Andi Kleen <andi@firstfloor.org> Cc: Jeff Mahoney <jeffm@suse.com> Cc: Chris Mason <chris.mason@oracle.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: Alexander Beregalov <a.beregalov@gmail.com> Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com> |
||
|---|---|---|
| .. | ||
| acpi | ||
| asm-generic | ||
| crypto | ||
| drm | ||
| keys | ||
| linux | ||
| math-emu | ||
| media | ||
| mtd | ||
| net | ||
| pcmcia | ||
| rdma | ||
| rxrpc | ||
| scsi | ||
| sound | ||
| trace | ||
| video | ||
| xen | ||
| Kbuild | ||