On 12/22/2015 08:25 AM, Christoph Lameter wrote:
> On Tue, 22 Dec 2015, Dave Hansen wrote:
>> On 12/21/2015 07:40 PM, Laura Abbott wrote:
>>> +	  The tradeoff is performance impact. The noticible impact can vary
>>> +	  and you are advised to test this feature on your expected workload
>>> +	  before deploying it
>>
>> What if instead of writing SLAB_MEMORY_SANITIZE_VALUE, we wrote 0's?
>> That still destroys the information, but it has the positive effect of
>> allowing a kzalloc() call to avoid zeroing the slab object.  It might
>> mitigate some of the performance impact.
> 
> We already write zeros in many cases or the object is initialized in a
> different. No one really wants an uninitialized object. The problem may be
> that a freed object is having its old content until reused. Which is
> something that poisoning deals with.

Or are you just saying that we should use the poisoning *code* that we
already have in slub?  Using the _code_ looks like a really good idea,
whether we're using it to write POISON_FREE, or 0's.  Something like the
attached patch?