mail archive Compressed Caching for Linux
linux-mm-cc.lists.laptop.org
(List home) (Recent threads) (86 other One Laptop per Child lists)
Subscription Options
- RSS or Atom: Read-only subscription using a browser or aggregator. This is the recommended way if you don't need to send messages to the list. You can learn more about feed syndication and clients here.
- Conventional: All messages are delivered to your mail address, and you can reply. To subscribe, send an email to the list's subscribe address with "subscribe" in the subject line, or visit the list's homepage here.
- Low traffic list: less than 3 messages per day
- This list contains about 551 messages, beginning Jun 2006
- 0 messages added yesterday
Report the Spam
This button sends a spam report to the moderator. Please use it sparingly. For other removal requests, read this.
Are you sure? yes no
swap-device write failure under low memory
Ad
Hello nitin,
Occasionally, xvMalloc will try to grow the pool.
This memory allocation can fail under low memory.
This will be informed to the kernel as a "device write" failure.
The page which was being written will not be reclaimed, but
the kernel will continue to try swap out of other pages ( as kernel
thinks that swap has free space. )
Wont this lead to the reclaim code ( kswapd or the direct reclaim
path ) hogging the processor for some time before OOM is
finally announced ?
And what if a NOFAIL allocation attempt results in this ?
Have you analysed this scenario ?
rgds,
shankar
Hi,On 07/07/2010 02:00 PM, Uma shankar wrote:
> Occasionally, xvMalloc will try to grow the pool.
> This memory allocation can fail under low memory.
>
> This will be informed to the kernel as a "device write" failure.
> The page which was being written will not be reclaimed, but
> the kernel will continue to try swap out of other pages ( as kernel
> thinks that swap has free space. )
>
> Wont this lead to the reclaim code ( kswapd or the direct reclaim
> path ) hogging the processor for some time before OOM is
> finally announced ?
>
> And what if a NOFAIL allocation attempt results in this ?
>
> Have you analysed this scenario ?
>If you ever get too many write failures, its an indication that you
have oversized ramzswap device. From what I have observed, swap write
failure quickly lead to system hang. In ideal case, ramzswap should
be able to dynamically resize based on cache hit-rate, system memory
pressure etc., but all this is not yet done. So, for now, best would
be to experiment a bit and get some idea of ramzswap disksize that helps
your workload while still not getting into messy conditions like OOM,
swap write failures.
Thanks,
Nitin
>
> If you ever get too many write failures, its an indication that you
> have oversized ramzswap device. From what I have observed, swap write
> failure quickly lead to system hang. In ideal case, ramzswap should
> be able to dynamically resize based on cache hit-rate, system memory
> pressure etc., but all this is not yet done. So, for now, best would
> be to experiment a bit and get some idea of ramzswap disksize that helps
> your workload while still not getting into messy conditions like OOM,
> swap write failures.
>
> Thanks,
> Nitin
>And also there is a small uncertainty of how many pages will be compressable.
A large Tmpfs file may get overcommitted at the time of initial
creation ( because most pages
are compressable at that time) , but may later induce OOM after a
later file-data-update
if many pages become uncompressable after the update. ( As of now,
75% of page-size
is the threshold in ramzswap. ).
I guess the problems with a large disksize value may be told to the
users in the
Readme file.