Page MenuHomeFreeBSD

vm_fault: do not trigger OOM too early
ClosedPublic

Authored by kib on Oct 4 2021, 6:43 AM.
Tags
None
Referenced Files
F106104463: D32287.id96200.diff
Wed, Dec 25, 11:36 AM
Unknown Object (File)
Tue, Dec 10, 10:08 PM
Unknown Object (File)
Nov 17 2024, 8:14 PM
Unknown Object (File)
Nov 17 2024, 5:52 PM
Unknown Object (File)
Nov 7 2024, 1:25 AM
Unknown Object (File)
Nov 7 2024, 1:24 AM
Unknown Object (File)
Oct 24 2024, 11:11 AM
Unknown Object (File)
Oct 24 2024, 11:11 AM
Subscribers

Details

Summary
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.

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Skipped
Unit
Tests Skipped

Event Timeline

kib requested review of this revision.Oct 4 2021, 6:43 AM
kib created this revision.
sys/vm/vm_fault.c
128

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?

kib marked an inline comment as done.Oct 4 2021, 3:31 PM
kib added inline comments.
sys/vm/vm_fault.c
1585

Don't we reset oom_started (it was oom counter before this patch) at line 1176?

This revision is now accepted and ready to land.Oct 4 2021, 3:44 PM
This revision was automatically updated to reflect the committed changes.