Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1305049

Re: [RFC PATCH] alispinlock: acceleration from lock integration on multi-core platform

From Ling Ma <ling.ma.program@gmail.com>
Newsgroups linux.kernel
Subject Re: [RFC PATCH] alispinlock: acceleration from lock integration on multi-core platform
Date 2016-01-09 00:00 +0100
Message-ID <qOOaK-4WG-11@gated-at.bofh.it> (permalink)
References <qLGCK-1YL-7@gated-at.bofh.it> <qNHbk-8sH-25@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


> So I have a whole bunch of problems with this thing.. For one I object
> to this being called a lock. Its much more like an async work queue like
> thing.
Ok, I will fix it.

> It suffers the typical problems all those constructs do; namely it
> wrecks accountability.
Ok, I will fix it.

> But here that is compounded by the fact that you inject other people's
> work into 'your' lock region, thereby bloating lock hold times. Worse,
> afaict (from a quick reading) there really isn't a bound on the amount
> of work you inject.
>
> This will completely wreck scheduling latency. At the very least the
> callback loop should have a need_resched() test on, but even that will
> not work if this has IRQs disabled.
>
>
> And while its a cute collapse of an MCS lock and lockless list style
> work queue (MCS after all is a lockless list), saving a few cycles from
> the naive spinlock+llist implementation of the same thing, I really
> do not see enough justification for any of this.
we can fix it if we really don't need it.

Thanks
Ling

Back to linux.kernel | Previous | NextPrevious in thread | Find similar | Unroll thread


Thread

Re: [RFC PATCH] alispinlock: acceleration from lock integration on  multi-core platform Peter Zijlstra <peterz@infradead.org> - 2016-01-05 22:20 +0100
  Re: [RFC PATCH] alispinlock: acceleration from lock integration on  multi-core platform One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> - 2016-01-05 22:50 +0100
    Re: [RFC PATCH] alispinlock: acceleration from lock integration on  multi-core platform Peter Zijlstra <peterz@infradead.org> - 2016-01-06 09:20 +0100
      Re: [RFC PATCH] alispinlock: acceleration from lock integration on  multi-core platform Peter Zijlstra <peterz@infradead.org> - 2016-01-06 09:30 +0100
        Re: [RFC PATCH] alispinlock: acceleration from lock integration on  multi-core platform One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> - 2016-01-06 12:30 +0100
          Re: [RFC PATCH] alispinlock: acceleration from lock integration on  multi-core platform Ling Ma <ling.ma.program@gmail.com> - 2016-01-08 23:50 +0100
            Re: [RFC PATCH] alispinlock: acceleration from lock integration on  multi-core platform One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> - 2016-01-12 15:00 +0100
              Re: [RFC PATCH] alispinlock: acceleration from lock integration on  multi-core platform Ling Ma <ling.ma.program@gmail.com> - 2016-01-14 09:20 +0100
    Re: [RFC PATCH] alispinlock: acceleration from lock integration on  multi-core platform Ling Ma <ling.ma.program@gmail.com> - 2016-01-09 00:10 +0100
  Re: [RFC PATCH] alispinlock: acceleration from lock integration on  multi-core platform Ling Ma <ling.ma.program@gmail.com> - 2016-01-09 00:00 +0100

csiph-web