You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Ala' Alkhaldi (JIRA)" <ji...@apache.org> on 2014/05/30 23:42:02 UTC

[jira] [Commented] (CASSANDRA-7316) Windows feature parity - lock virtual address space via VirtualLock

    [ https://issues.apache.org/jira/browse/CASSANDRA-7316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14014251#comment-14014251 ] 

Ala' Alkhaldi commented on CASSANDRA-7316:
------------------------------------------

I am assuming that the goal is to lock the current and the future virtual pages allocated by the JVM. This assumption is based on the deployment recommendation of turnning swap off in Linux environment [[1|http://www.datastax.com/documentation/cassandra/2.0/cassandra/install/installRecommendSettings.html]] .

*A question about mlockall:
_mlockall(MCL_CURRENT)_ is called during CassandraDaemon.setup(). It only locks the virtual pages which are +currently mapped+ into the address space of the process [[2|http://linux.die.net/man/2/mlockall]], virtual memory pages that will be allocated in the future are subject to swapping. I wonder about the actual advantage of calling this Linux API at an early stage of the setup. If the goal is to lock the current as well as the future pages of the JVM, why do not we use _MCL_FUTURE_ flag or at least delay the current call to the end of the setup?

*VirtualLock:
Locks a specific region of the process's virtual address space into physical memory via a handle to that memory region. Such handle is usually obtained by explicitly allocating memory using VirtualAlloc() function. Windows does not provide an API to retrieve a handle on the virtual memory acquired by the current process, which means that _virtualLock()_ can not be used to lock the virtual address space of the JVM.  In the contrary, mlockall locks the pages of the current page without needing a handle.

*Solution:
I suggest using _Large Memory Pages_. In addition to optimizing the lookup time of the TLP, large memory pages are locked in the physical memory (can not be paged out) in Windows environment [[3| http://msdn.microsoft.com/en-us/library/windows/desktop/aa366720(v=vs.85).aspx]]. This can be done by just passing an extra option to the JVM (-XX:+UseLargePages [[4|http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html]]). 
If this is an acceptable solution, I will go ahead an evaluate it.




> Windows feature parity - lock virtual address space via VirtualLock
> -------------------------------------------------------------------
>
>                 Key: CASSANDRA-7316
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-7316
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Joshua McKenzie
>            Assignee: Ala' Alkhaldi
>            Priority: Minor
>              Labels: Windows, perfomance
>             Fix For: 3.0
>
>
> Similar to mlockall() in CLibrary.java for linux, it would be nice to lock the virtual address space on Windows to prevent page faults.  Reference API:  http://msdn.microsoft.com/en-us/library/windows/desktop/aa366895(v=vs.85).aspx



--
This message was sent by Atlassian JIRA
(v6.2#6252)