On Wed, Feb 6, 2013 at 12:10 PM, Rik van Riel <r...@redhat.com> wrote: > On 01/27/2013 08:04 AM, Michel Lespinasse wrote: >> >> On Fri, Jan 25, 2013 at 11:18 AM, Rik van Riel <r...@redhat.com> wrote: >>> >>> + u32 delay = (ent->hash == hash) ? ent->delay : >>> MIN_SPINLOCK_DELAY; >> >> I still don't like the reseting of delay to MIN_SPINLOCK_DELAY when >> there is a hash collision. > > I've been spending some time looking at this, because I am > not a fan either. > > However, it seems to work and I failed to come up with > anything better. Therefore, I have left it as is in the > -v5 patch series.
Does that mean you know of workloads that would regress if you didn't reset the delay to MIN_SPINLOCK_DELAY when detecting a hash collision ? I have not seen any public reports of that... -- Michel "Walken" Lespinasse A program is never fully debugged until the last user dies. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
