On 12/18/17 12:41 AM, Michal Hocko wrote:
On Sat 16-12-17 23:09:25, Kirill A. Shutemov wrote:
On Sat, Dec 16, 2017 at 12:45:25PM +0100, Michal Hocko wrote:
On Sat 16-12-17 04:04:10, Yang Shi wrote:
[...]
Shall we add "cond_resched()" in unmap_vmas(), i.e for every 100 vmas? It
may improve the responsiveness a little bit for non-preempt kernel, although
it still can't release the semaphore.
We already do, once per pmd (see zap_pmd_range).
It doesn't help. We would need to find a way to drop mmap_sem, if we're
holding it way too long. And doing it on per-vma count basis is not right
call. It won't address issue with single huge vma.
Absolutely agreed. I just wanted to point out that a new cond_resched is
not really needed. One way to reduce the lock starvation is to use range
locking.
It looks the range locking development is stalled?
Yang
Do we have any instrumentation that would help detect starvation on a
rw_semaphore?
I am afraid we don't.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
