Hi Dave,
Thank you, I will reinstate the check in memcpy() to limit it to 2G
memcpy(). Are you OK with keeping the change of icc to xcc for
consistency, or should I revert it as well?
N4memset() never had this length bound check, and it bit met when I was
testing the time it takes to zero large hash tables. Are you OK to keep
the change in memset()?
Also, for consideration, machines are getting bigger, and 2G is becoming
very small compared to the memory sizes, so some algorithms can become
inefficient when they have to artificially limit memcpy()s to 2G chunks.
X6-8 scales up to 6T:
http://www.oracle.com/technetwork/database/exadata/exadata-x6-8-ds-2968796.pdf
SPARC M7-16 scales up to 16T:
http://www.oracle.com/us/products/servers-storage/sparc-m7-16-ds-2687045.pdf
2G is just 0.012% of the total memory size on M7-16.
Thank you,
Pasha
On 2017-02-28 10:12, David Miller wrote:
From: Pavel Tatashin <pasha.tatashin@xxxxxxxxxx>
Date: Tue, 28 Feb 2017 09:55:44 -0500
@@ -252,19 +248,16 @@ FUNC_NAME: /* %o0=dst, %o1=src, %o2=len */
#ifdef MEMCPY_DEBUG
wr %g0, 0x80, %asi
#endif
- srlx %o2, 31, %g2
- cmp %g2, 0
- tne %XCC, 5
PREAMBLE
mov %o0, %o3
brz,pn %o2, .Lexit
This limitation was placed here intentionally, because huge values
are %99 of the time bugs and unintentional.
You will see that every assembler optimized memcpy on sparc64 has
this bug trap, not just NG4.
This is a very useful way to find bugs and length {over,under}flows.
Please do not remove it.
If you have to do 4GB or larger copies, do it in pieces or similar.
Thank you.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
