lkml.org 
[lkml]   [2012]   [Jul]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH 0/2] [RFC] Volatile ranges (v4)
Date
John Stultz <john.stultz <at> linaro.org> writes:
> Ok. So here's another iteration of the fadvise volatile range code.
>
> I realize this is still a way off from being ready, but I wanted to post
> what I have to share with folks working on the various range/interval
> management ideas as well as update folks who've provided feedback on the
> volatile range code.

Hi John,

May you please confirm whether the fadvise(FADV_VOLATILE)
will work for me in the following case?
I am developing a dynamic data race detector (ThreadSanitizer).
It needs to associate some meta-data (shadow) with each byte
of application memory (4 bytes of shadow for 1 byte of app
memory). We mmap(MAP_ANONYMOUS|MAP_NORESERVE)
40TB of virtual address space for
shadow, and then just access it as needed. It works.
But for some apps that consume too much
memory, it eventually leads to swapping/OOM kills.
There is a property of shadow memory that I would like to exploit
- any region of shadow memory can be reset to zero at any point
w/o any bad consequences (it can lead to missed data
races, but it's better than OOM kill).
I've tried to execute madvise(MADV_DONTNEED) every X
seconds for whole shadow memory. It almost works.
The problem is that madvise() seems to be
not atomic, occasionally I see missed writes, that's not acceptable,
I need either zero pages or
consistent pages.
Your FADV_VOLATILE looks like it may be the solution.
To summarize: I have a huge region of memory that
I would like to mark as "volatile" at program
startup. The region is anonymous (not backed by any file).
The kernel must be able to take away
any pages in the range, and then return zero pages later.
I do have concurrent writes to the
range, and missed writes are unacceptable.
Ideally, pages are revoked on LRU basis
TIA



\
 
 \ /
  Last update: 2012-07-19 13:01    [W:0.125 / U:0.160 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site