User: Password:
|
|
Subscribe / Log in / New account

Avoiding swap IO with mem_notify

Avoiding swap IO with mem_notify

Posted Feb 2, 2008 17:49 UTC (Sat) by riel (subscriber, #3142)
In reply to: Avoiding the OOM killer with mem_notify by droundy
Parent article: Avoiding the OOM killer with mem_notify

The patch series is indeed designed primarily to increase system performance by avoiding the
IO penalty of swapping out (and back in) memory that contains data that is useless or can be
easily recalculated.

Decompressing (part of) a jpeg just has to be faster than swapping in something from disk,
simply because disk seek times are on the order of 10ms.

Avoiding the OOM killer is a secondary goal.  I am not sure why that is the headline of the
article...


(Log in to post comments)

Avoiding swap IO with mem_notify

Posted Feb 3, 2008 4:14 UTC (Sun) by njs (guest, #40338) [Link]

Oh!  This makes *much* more sense.  (Especially the otherwise unintelligible part of the
original article that talks about pages getting swapped out, which has nothing to do with
OOM.)

In fairness, though, the LKML patch announcement just talks about it being good to avoid the
OOM.

Avoiding swap IO with mem_notify

Posted Feb 3, 2008 21:02 UTC (Sun) by oak (guest, #2786) [Link]

The article talks also about embedded systems. Those use use flash which 
doesn't suffer from the seek problem like hard disks do.  On embedded 
memory usage is much more of a problem though and kernel gets pretty slow 
too on devices without swap when memory gets really tight (all kernel does 
is page read-only pages from disk to memory and then discard them again 
until it finally does an OOM-kill).

I thought the point of the patch is for user-space to be able to do the  
memory management in *manageable places* in code.   As mentioned earlier, 
a lot of user-space code[1] doesn't handle memory allocation failures. And 
even if it's supposed to be, it can be hard to verify (test) that the 
failures are handled in *all* cases properly.  If user-space can get a 
pre-notification of a low-memory situation, it can in suitable place in 
code free memory so that further allocations will succeed (with higher 
propability). 

That also allows doing somehing like what maemo does.  If system gets 
notified about kernel low memory shortage, it kills processes which have 
notified it that they are in "background-killable" state (saved their UI 
state, able to restore it and not currently visible to user). I think it 
also notifies applications (currently) through D-BUS about low memory 
condition. Applications visible to user or otherwise non-background 
killable are then supposed to free their caches and/or disable features 
that could take a lot of additional memory.  If the caches are from heap 
instead of memory mapped, it's less likely to help because of heap 
fragmentation and it requiring more work/time though.

[1] Glib and anything built on top of it, like Gtk, assume that if process 
is still running, it got the memory, otherwise it's aborted.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds