Messages in this thread | | | From | Linus Torvalds <> | Date | Sun, 20 Aug 2023 14:59:07 +0200 | Subject | Re: [PATCH] mm: remove unintentional voluntary preemption in get_mmap_lock_carefully |
| |
On Sun, 20 Aug 2023 at 14:47, Linus Torvalds <torvalds@linux-foundation.org> wrote: > > But without that odd ifdef, I think it's fine.
Another option might be to just move the might_sleep() to the top, and do it unconditionally. If the trylock fails, the overhead of possibly doing a cond_resched() is kind of moot.
IOW, the main problem here is not that it causes a scheduling point (if the kernel isn't preemptable), it seems to be just that we unnecessarily schedule in a place with the mm lock is held, so it unnecessarily causes possible lock contention for writers.
With the per-vma locking catching most cases, does any of this even matter?
Mateusz - on that note: I'm wondering what made you see this as a problem. The case you quote doesn't actually seem to be threaded, so the vm lock contention shouldn't actually matter there.
Does it schedule away? Sure. But only if "needs_resched" is set, so it doesn't seem to be a *bad* thing per se.
It might just be that this particular scheduling point ends up being a common one on that load, and with those kernel config options (ie PREEMPT_VOLUNTARY)?
Linus
| |