Re: [RFC][PATCH 0/3] Speed up SLUB poisoning + disable checks

On Wed, 3 Feb 2016, Laura Abbott wrote: > I also notice that __CMPXCHG_DOUBLE is turned off when the debug > options are turned on. I don't see any details about why. What's > the reason for turning it off when the debug options are enabled? Because operations on the object need to be locked out

Re: [RFC][PATCH 0/3] Speed up SLUB poisoning + disable checks

On 02/03/2016 03:02 PM, Christoph Lameter wrote: The fast path uses the per cpu caches. No locks are taken and there is no IRQ disabling. For concurrency protection this comment explains it best: /* * The cmpxchg will only match if there was no additional * operation and if we are on the

Re: [RFC][PATCH 0/3] Speed up SLUB poisoning + disable checks

> The fast path uses the per cpu caches. No locks are taken and there > is no IRQ disabling. For concurrency protection this comment > explains it best: > > /* > * The cmpxchg will only match if there was no additional > * operation and if we are on the right processor. > * > * The cmpxchg

Re: [RFC][PATCH 0/3] Speed up SLUB poisoning + disable checks

On 02/03/2016 01:06 PM, Kees Cook wrote: On Wed, Feb 3, 2016 at 10:46 AM, Laura Abbott wrote: On 01/25/2016 11:03 PM, Joonsoo Kim wrote: On Mon, Jan 25, 2016 at 05:15:10PM -0800, Laura Abbott wrote: Hi, Based on the discussion from the series to add slab sanitization

Re: [RFC][PATCH 0/3] Speed up SLUB poisoning + disable checks

On Wed, Feb 3, 2016 at 10:46 AM, Laura Abbott wrote: > On 01/25/2016 11:03 PM, Joonsoo Kim wrote: >> >> On Mon, Jan 25, 2016 at 05:15:10PM -0800, Laura Abbott wrote: >>> >>> Hi, >>> >>> Based on the discussion from the series to add slab sanitization >>>

Re: [RFC][PATCH 0/3] Speed up SLUB poisoning + disable checks

On 01/25/2016 11:03 PM, Joonsoo Kim wrote: On Mon, Jan 25, 2016 at 05:15:10PM -0800, Laura Abbott wrote: Hi, Based on the discussion from the series to add slab sanitization (lkml.kernel.org/g/<1450755641-7856-1-git-send-email-la...@labbott.name>) the existing SLAB_POISON mechanism already

Re: [RFC][PATCH 0/3] Speed up SLUB poisoning + disable checks

On Wed, Feb 3, 2016 at 10:46 AM, Laura Abbott wrote: > On 01/25/2016 11:03 PM, Joonsoo Kim wrote: >> >> On Mon, Jan 25, 2016 at 05:15:10PM -0800, Laura Abbott wrote: >>> >>> Hi, >>> >>> Based on the discussion from the series to add slab sanitization >>>

Re: [RFC][PATCH 0/3] Speed up SLUB poisoning + disable checks

On 02/03/2016 01:06 PM, Kees Cook wrote: On Wed, Feb 3, 2016 at 10:46 AM, Laura Abbott wrote: On 01/25/2016 11:03 PM, Joonsoo Kim wrote: On Mon, Jan 25, 2016 at 05:15:10PM -0800, Laura Abbott wrote: Hi, Based on the discussion from the series to add slab sanitization

Re: [RFC][PATCH 0/3] Speed up SLUB poisoning + disable checks

> The fast path uses the per cpu caches. No locks are taken and there > is no IRQ disabling. For concurrency protection this comment > explains it best: > > /* > * The cmpxchg will only match if there was no additional > * operation and if we are on the right processor. > * > * The cmpxchg

Re: [RFC][PATCH 0/3] Speed up SLUB poisoning + disable checks

On 02/03/2016 03:02 PM, Christoph Lameter wrote: The fast path uses the per cpu caches. No locks are taken and there is no IRQ disabling. For concurrency protection this comment explains it best: /* * The cmpxchg will only match if there was no additional * operation and if we are on the

Re: [RFC][PATCH 0/3] Speed up SLUB poisoning + disable checks

On Wed, 3 Feb 2016, Laura Abbott wrote: > I also notice that __CMPXCHG_DOUBLE is turned off when the debug > options are turned on. I don't see any details about why. What's > the reason for turning it off when the debug options are enabled? Because operations on the object need to be locked out

Re: [RFC][PATCH 0/3] Speed up SLUB poisoning + disable checks

On 01/25/2016 11:03 PM, Joonsoo Kim wrote: On Mon, Jan 25, 2016 at 05:15:10PM -0800, Laura Abbott wrote: Hi, Based on the discussion from the series to add slab sanitization (lkml.kernel.org/g/<1450755641-7856-1-git-send-email-la...@labbott.name>) the existing SLAB_POISON mechanism already

Re: [RFC][PATCH 0/3] Speed up SLUB poisoning + disable checks

2016-01-27 0:01 GMT+09:00 Christoph Lameter : > On Tue, 26 Jan 2016, Joonsoo Kim wrote: > >> I doesn't follow up that discussion, but, I think that reusing >> SLAB_POISON for slab sanitization needs more changes. I assume that >> completeness and performance is matter for slab sanitization. >> >>

Re: [RFC][PATCH 0/3] Speed up SLUB poisoning + disable checks

On Tue, 26 Jan 2016, Joonsoo Kim wrote: > I doesn't follow up that discussion, but, I think that reusing > SLAB_POISON for slab sanitization needs more changes. I assume that > completeness and performance is matter for slab sanitization. > > 1) SLAB_POISON isn't applied to specific kmem_cache

Re: [RFC][PATCH 0/3] Speed up SLUB poisoning + disable checks

On Mon, 25 Jan 2016, Laura Abbott wrote: > slub_debug=-: 7.437 > slub_debug=-: 7.932 So thats an almost 10% performance regression if the feature is not used. The reason that posoning is on the slow path is because it is impacting performance. Focus on optimizing the debug path without

Re: [RFC][PATCH 0/3] Speed up SLUB poisoning + disable checks

On Mon, 25 Jan 2016, Laura Abbott wrote: > slub_debug=-: 7.437 > slub_debug=-: 7.932 So thats an almost 10% performance regression if the feature is not used. The reason that posoning is on the slow path is because it is impacting performance. Focus on optimizing the debug path without

Re: [RFC][PATCH 0/3] Speed up SLUB poisoning + disable checks

On Tue, 26 Jan 2016, Joonsoo Kim wrote: > I doesn't follow up that discussion, but, I think that reusing > SLAB_POISON for slab sanitization needs more changes. I assume that > completeness and performance is matter for slab sanitization. > > 1) SLAB_POISON isn't applied to specific kmem_cache

Re: [RFC][PATCH 0/3] Speed up SLUB poisoning + disable checks

2016-01-27 0:01 GMT+09:00 Christoph Lameter : > On Tue, 26 Jan 2016, Joonsoo Kim wrote: > >> I doesn't follow up that discussion, but, I think that reusing >> SLAB_POISON for slab sanitization needs more changes. I assume that >> completeness and performance is matter for slab

Re: [RFC][PATCH 0/3] Speed up SLUB poisoning + disable checks

On Mon, Jan 25, 2016 at 05:15:10PM -0800, Laura Abbott wrote: > Hi, > > Based on the discussion from the series to add slab sanitization > (lkml.kernel.org/g/<1450755641-7856-1-git-send-email-la...@labbott.name>) > the existing SLAB_POISON mechanism already covers similar behavior. > The

[RFC][PATCH 0/3] Speed up SLUB poisoning + disable checks

Hi, Based on the discussion from the series to add slab sanitization (lkml.kernel.org/g/<1450755641-7856-1-git-send-email-la...@labbott.name>) the existing SLAB_POISON mechanism already covers similar behavior. The performance of SLAB_POISON isn't very good. With hackbench -g 20 -l 1000 on QEMU

Re: [RFC][PATCH 0/3] Speed up SLUB poisoning + disable checks

On Mon, Jan 25, 2016 at 05:15:10PM -0800, Laura Abbott wrote: > Hi, > > Based on the discussion from the series to add slab sanitization > (lkml.kernel.org/g/<1450755641-7856-1-git-send-email-la...@labbott.name>) > the existing SLAB_POISON mechanism already covers similar behavior. > The

[RFC][PATCH 0/3] Speed up SLUB poisoning + disable checks

Hi, Based on the discussion from the series to add slab sanitization (lkml.kernel.org/g/<1450755641-7856-1-git-send-email-la...@labbott.name>) the existing SLAB_POISON mechanism already covers similar behavior. The performance of SLAB_POISON isn't very good. With hackbench -g 20 -l 1000 on QEMU