@gibbs: "avg pointed out the rate limiting code in vm_pageout_scan() during discussi=
on about PR 187594.  While it certainly can contribute to the problems disc=
ussed in that PR, a bigger problem is that it can allow the OOM killer to b=
e triggered even though there is plenty of reclaimable memory available in =
the system.  Any load that can consume enough pages within the polling inte=
rval to hit the v_free_min threshold (e.g. multiple 'dd if=3D/dev/zero of=
=3D/file/on/zfs') can make this happen.
The product I=92m working on does not have swap configured and treats any O=
OM trigger as fatal, so it is very obvious when this happens. :-)
I=92ve tried several things to mitigate the problem.  The first was to igno=
re rate limiting for pass 2.  However, even though ZFS is guaranteed to rec=
eive some feedback prior to OOM being declared, my testing showed that a tr=
ivial load (a couple dd operations) could still consume enough of the recla=
imed space to leave the system below its target at the end of pass 2.  Afte=
r removing the rate limiting entirely, I=92ve so far been unable to kill th=
e system via a ZFS induced load.
I understand the motivation behind the rate limiting, but the current imple=
mentation seems too simplistic to be safe.  The documentation for the Solar=
is slab allocator provides good motivation for their approach of using a =
=93sliding average=94 to reign in temporary bursts of usage without unduly =
harming efficient service for the recorded steady-state memory demand.  Reg=
ardless of the approach taken, I believe that the OOM killer must be a last=
 resort and shouldn=92t be called when there are caches that can be culled.
One other thing I=92ve noticed in my testing with ZFS is that it needs feed=
back and a little time to react to memory pressure.  Calling it=92s lowmem =
handler just once isn=92t enough for it to limit in-flight writes so it can=
 avoid reuse of pages that it just freed up.  But, it doesn=92t take too lo=
ng to react (> 1sec in the profiling I=92ve done).  Is there a way in vm_pa=
geout_scan() that we can better record that progress is being made (pages w=
ere freed in the pass, even if some/all of them were consumed again) and al=
low more passes before the OOM killer is invoked in this case?
=97
Justin
_______________________________________________
<email_address> mailing list
<url>
To unsubscribe, send any mail to "<email_address>""
    @avg: "<quote>
sion
ssed
the
al
 OOM
nore
ive
al
ng a
FWIW, I have this toy branch:
<url>
Not all commits are relevant to the problem and some things are unfinished.
Not sure if the changes would help your case either...
edback
dler
 reuse
 (>
I've been thinking about this and maybe we need to make arc_memory_throttle=
()
more aggressive on FreeBSD.  I can't say that I really follow the logic of =
that
code, though.
that
 =
Andriy Gapon
_______________________________________________
<email_address> mailing list
<url>
To unsubscribe, send any mail to "<email_address>""
    @avg: "<quote>
As I've mentioned, arc_memory_throttle() also plays role in limiting the dirty data.
Andriy Gapon
_______________________________________________
<email_address> mailing list
<url>
To unsubscribe, send any mail to "<email_address>""
{'source': 'USENET', 'other_information': '{"reply_count": 2, "forum_name": "muc.lists.freebsd.current.20150814.mbox"}', 'file': 'data/output/usenet-muc.lists.parquet'}