Wakeup in vm_waitpfault() does not mean that the thread would get the page on the next vm_page_alloc() call, other thread might steal the free page we were waiting for. On the other hand, this wakeup might come much earlier than just vm_pfault_oom_wait seconds, if the rate of the page reclamation is high enough. If wakeups come fast and we loose the allocation race enough times, OOM could be undeservably triggered much earlier than vm_pfault_oom_attempts x vm_pfault_oom_wait seconds. Fix it by not counting the number of sleeps, but measuring the time to th first allocation failure, and triggering OOM when it was older than oom_attempts x oom_wait seconds.
Details
Details
- Reviewers
alc markj - Commits
- rG174aad047e12: vm_fault: do not trigger OOM too early
Diff Detail
Diff Detail
- Repository
- rG FreeBSD src repository
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
| sys/vm/vm_fault.c | ||
|---|---|---|
| 128–129 | oom_start_time would be a better name, IMO. first_tick sounds like a ticks value. | |
| 1585 | Suppose fs.oom_started is true here, i.e., the faulting thread slept for some time but allocated a page before triggering an OOM kill. Shouldn't we reset OOM state before trying the allocation here? | |
| sys/vm/vm_fault.c | ||
|---|---|---|
| 1585 | Don't we reset oom_started (it was oom counter before this patch) at line 1176? | |