Re: [PATCH v10 00/16] Volatile Ranges v10

[John Stultz <john.stultz@linaro.org>]

On 01/27/2014 02:23 PM, KOSAKI Motohiro wrote:
> Hi Minchan,
>
>
> On Thu, Jan 2, 2014 at 2:12 AM, Minchan Kim <minchan@kernel.org> wrote:
>> Hey all,
>>
>> Happy New Year!
>>
>> I know it's bad timing to send this unfamiliar large patchset for
>> review but hope there are some guys with freshed-brain in new year
>> all over the world. :)
>> And most important thing is that before I dive into lots of testing,
>> I'd like to make an agreement on design issues and others
>>
>> o Syscall interface
>> o Not bind with vma split/merge logic to prevent mmap_sem cost and
>> o Not bind with vma split/merge logic to avoid vm_area_struct memory
>>   footprint.
>> o Purging logic - when we trigger purging volatile pages to prevent
>>   working set and stop to prevent too excessive purging of volatile
>>   pages
>> o How to test
>>   Currently, we have a patched jemalloc allocator by Jason's help
>>   although it's not perfect and more rooms to be enhanced but IMO,
>>   it's enough to prove vrange-anonymous. The problem is that
>>   lack of benchmark for testing vrange-file side. I hope that
>>   Mozilla folks can help.
>>
>> So its been a while since the last release of the volatile ranges
>> patches, again. I and John have been busy with other things.
>> Still, we have been slowly chipping away at issues and differences
>> trying to get a patchset that we both agree on.
>>
>> There's still a few issues, but we figured any further polishing of
>> the patch series in private would be unproductive and it would be much
>> better to send the patches out for review and comment and get some wider
>> opinions.
>>
>> You could get full patchset by git
>>
>> git clone -b vrange-v10-rc5 --single-branch git://git.kernel.org/pub/scm/linux/kernel/git/minchan/linux.git
> Brief comments.
>
> - You should provide jemalloc patch too. Otherwise we cannot
> understand what the your mesurement mean.
> - Your number only claimed the effectiveness anon vrange, but not file vrange.
> - Still, Nobody likes file vrange. At least nobody said explicitly on
> the list. I don't ack file vrange part until
>   I fully convinced Pros/Cons. You need to persuade other MM guys if
> you really think anon vrange is not
>   sufficient. (Maybe LSF is the best place)

I do agree that the semantics for volatile-ranges on files is more
difficult for folks to grasp (and like after doing so). I've almost
gotten to the point (as I've discussed with Minchan privately) where I'm
willing to hold back on volatile-ranges on files in the shrort-term just
to see if it helps to get key mm folks to review and comment the
volatile-ranges on anonymous memory.

That said, I do think volatile ranges on files is an important concept,
and I'd like to make sure we don't design something that can't be used
for files in the future.

Part of the major interest in volatile memory has been from web
browsers. Both Chrome and Firefox are already making use of the
file-based ashmem, where available, in order to have this "discardable
memory" feature.

And while the Mozilla developers don't see file based volatile memory as
critical right now for their needs, I can imagine as they continue to
work on multi-process firefox
(http://billmccloskey.wordpress.com/2013/12/05/multiprocess-firefox/)
for performance and security reasons, the need to have memory volatility
shared between processes will become more important.


thanks
-john

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>