[
https://issues.apache.org/jira/browse/HDFS-4953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13708931#comment-13708931
]
Colin Patrick McCabe commented on HDFS-4953:
--------------------------------------------
bq. I think you have changed this by mistake?
Yeah, I'm not sure how that got in there.
bq. I think, if we read different blocks data here, we need to map for each
separately right? So, cache gets filled quickly and what is the result with
this kind of scenario?
When the cache is full, and someone wants to mmap and additional block, we
have to evict something. If something can't be evicted, we simply do not mmap.
In general, mmap will obviously be a much bigger win for programs which access
the same files over and over, than for files which have a "scan" type workload.
One way to think about it is that mmap reduces the CPU bottleneck of read
operations. But if your reads are hitting disk, that bottleneck is irrelevant
since you are waiting for I/O. This is inherent in the way mmap works.
bq. Also for smaller files, this may be overhead right as mapping overhead may
be more than reads. (can add minimum block size for mmap?)
It seems reasonable for me for people to have small files in the mmap cache if
they are read frequently. Whether or not the file is accessed frequently is a
better predictor of how much performance benefit we'll get than block size, I
believe.
Another thing to note is that this work will eventually be integrated with the
ongoing caching work in HDFS-4949. Our first pass will probably be only
allowing mmap on blocks which are already in the HDFS-4949 cache.
bq. Did you try implementing native call for unmap instead of depending on Sun
package. In fact I too introduced dependency on this cleaner code when I try
introducing this on write path at DNs in my internal branch.
Yeah, it's a shame we have to add that. However, not everyone runs with the
native code enabled. I would hesitate to add a dependency that was not really
needed. What benefit do you think there would be of using JNI for this?
> enable HDFS local reads via mmap
> --------------------------------
>
> Key: HDFS-4953
> URL: https://issues.apache.org/jira/browse/HDFS-4953
> Project: Hadoop HDFS
> Issue Type: New Feature
> Affects Versions: 2.2.0
> Reporter: Colin Patrick McCabe
> Assignee: Colin Patrick McCabe
> Attachments: benchmark.png, HDFS-4953.001.patch, HDFS-4953.002.patch
>
>
> Currently, the short-circuit local read pathway allows HDFS clients to access
> files directly without going through the DataNode. However, all of these
> reads involve a copy at the operating system level, since they rely on the
> read() / pread() / etc family of kernel interfaces.
> We would like to enable HDFS to read local files via mmap. This would enable
> truly zero-copy reads.
> In the initial implementation, zero-copy reads will only be performed when
> checksums were disabled. Later, we can use the DataNode's cache awareness to
> only perform zero-copy reads when we know that checksum has already been
> verified.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
