Re: [PATCH 0/2] [RFC] Volatile ranges (v4)

From: Dmitry Vyukov
Date: Thu Jul 19 2012 - 06:15:07 EST

John Stultz <john.stultz <at>> 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
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

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at