On 12/22/15 10:19 AM, Dave Hansen wrote:
On 12/22/2015 10:08 AM, Christoph Lameter wrote:
On Tue, 22 Dec 2015, Dave Hansen wrote:
Why would you use zeros? The point is just to clear the information right?
The regular poisoning does that.
It then allows you to avoid the zeroing at allocation time.
Well much of the code is expecting a zeroed object from the allocator and
its zeroed at that time. Zeroing makes the object cache hot which is an
important performance aspect.
Yes, modifying this behavior has a performance impact. It absolutely
needs to be evaluated, and I wouldn't want to speculate too much on how
good or bad any of the choices are.
Just to reiterate, I think we have 3 real choices here:
1. Zero at alloc, only when __GFP_ZERO
(behavior today)
2. Poison at free, also Zero at alloc (when __GFP_ZERO)
(this patch's proposed behavior, also what current poisoning does,
doubles writes)
3. Zero at free, *don't* Zero at alloc (when __GFP_ZERO)
(what I'm suggesting, possibly less perf impact vs. #2)
poisoning with non-zero memory makes it easier to determine that the error
came from accessing the sanitized memory vs. some other case. I don't think
the feature would be as strong if the memory was only zeroed vs. some other
data value.
Thanks,
Laura
--
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>