Details
-
Improvement
-
Resolution: Fixed
-
Minor
-
None
-
9223372036854775807
Description
The purpose is that the client can cache max_cached_mb at maximum on the client side but if the memory is in pressure it should consume less by hooking it up to cache shrinker.
Attachments
Issue Links
- is related to
-
LU-5841 Lustre 2.4.2 MDS, hitting OOM errors
-
- Resolved
-
Activity
memhog is a test program under $LUSTRE/lustre/test. It just allocates a huge amount of memory so that we can investigate if Lustre does well under memory pressure.
Cliff - Can you explain the tests results a bit more? What's memhog, for example? Is all the testing with the patch installed? If so, are there non-patched results somewhere to compare to?
So this shrinker just reduce the ccc_lru_max, and of course shrink LRU if ccc_lru_left is not enough. I'm wondering when the ccc_lru_max should be restored gradually when the memory is not under such pressure?
Sorry for delay response.
This is not about reducing ccc_lru_max, which we don't need to adjust in this case. Actually the meaning of ccc_lru_max should be 'to cache this many pages if memory is enough'. When the system memory is under pressure, Lustre shouldn't cache that much memory at all.
We should register a cache shrinker on the OSC layer to get rid of some pages under memory pressure. Please take a look at osc_lru_reclaim(), but instead we are going to iterate each individual client_obd and destroy pages from them by the policies of last use, # of pages cached, etc.
Bobi Jam (bobijam@hotmail.com) uploaded a new patch: http://review.whamcloud.com/15630
Subject: LU-6842 clio: limit max cl_page LRU thru shrinker
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: a7cf7b259c93d0f30f390b142878f137d7791ba4
So this shrinker just reduce the ccc_lru_max, and of course shrink LRU if ccc_lru_left is not enough. I'm wondering when the ccc_lru_max should be restored gradually when the memory is not under such pressure?
Added 2.7.56 results for comparison