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

Groups > linux.kernel > #1181782 > unrolled thread

Re: [Ksummit-discuss] [CORE TOPIC] lightweight per-cpu locks / restartable sequences

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [Ksummit-discuss] [CORE TOPIC] lightweight per-cpu locks /  restartable sequences Christoph Lameter <cl@linux.com> - 2015-07-10 19:30 +0200
    Re: [Ksummit-discuss] [CORE TOPIC] lightweight per-cpu locks /  restartable sequences Peter Zijlstra <peterz@infradead.org> - 2015-07-13 12:00 +0200
      Re: [Ksummit-discuss] [CORE TOPIC] lightweight per-cpu locks /  restartable sequences Andy Lutomirski <luto@amacapital.net> - 2015-07-14 22:10 +0200

#1181782 — Re: [Ksummit-discuss] [CORE TOPIC] lightweight per-cpu locks / restartable sequences

On Thu, 9 Jul 2015, Chris Mason wrote:

> I think the topic is really interesting and we'll be able to get numbers
> from production workloads to help justify and compare different
> approaches.

Ok that would be important. I also think that the approach may be used
in kernel to reduce the overhead of CONFIG_PREEMPT and also to implement
fast versions of this_cpu_ops for non x86 architectures and maybe even
optimize the x86 variants if interrupts also can detect critical sections
and restart at defined points.



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1182675

On Fri, Jul 10, 2015 at 12:26:21PM -0500, Christoph Lameter wrote:
> On Thu, 9 Jul 2015, Chris Mason wrote:
> 
> > I think the topic is really interesting and we'll be able to get numbers
> > from production workloads to help justify and compare different
> > approaches.
> 
> Ok that would be important. I also think that the approach may be used
> in kernel to reduce the overhead of CONFIG_PREEMPT and also to implement
> fast versions of this_cpu_ops for non x86 architectures and maybe even

There is nothing stopping people from trying this in-kernel, in fact
that would be lots easier as we do not have to commit to any one
specific ABI for that.

Also, I don't think we need a schedule check for the in-kernel usage,
pure interrupt should be good enough, nobody should (want to) call
schedule() while inside such a critical section, which leaves us with
involuntary preemption, and those are purely interrupt driven.

Now the 'problem' is finding these special regions fast, the easy
solution is the same as the one proposed for userspace, one big section.
That way the interrupt only has to check if the IP is inside this
section which is minimal effort.

The down side is that all percpu ops would then end up being full
function calls. Which on some archs is indeed faster than disabling
interrupts, but not by much I'm afraid.

> optimize the x86 variants if interrupts also can detect critical sections
> and restart at defined points.

I really don't see how we can beat %GS prefixes with any such scheme.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1183957

On Mon, Jul 13, 2015 at 7:01 AM, Christoph Lameter <cl@linux.com> wrote:
> On Mon, 13 Jul 2015, Peter Zijlstra wrote:
>
>> Now the 'problem' is finding these special regions fast, the easy
>> solution is the same as the one proposed for userspace, one big section.
>> That way the interrupt only has to check if the IP is inside this
>> section which is minimal effort.
>>
>> The down side is that all percpu ops would then end up being full
>> function calls. Which on some archs is indeed faster than disabling
>> interrupts, but not by much I'm afraid.
>
> Well one could move the entire functions that are using these ops into the
> special sections. That is certainly an area requiring much more thought.

Hmm.

>
>> > optimize the x86 variants if interrupts also can detect critical sections
>> > and restart at defined points.
>>
>> I really don't see how we can beat %GS prefixes with any such scheme.
>
> We may be able to avoid RMV sequences which allows the processor to better
> schedule operations.

True, but cmpxchg is, surprisingly, pretty fast.

Crazy thought: At the risk of proposing something ridiculous, what if
we had per-cpu memory mappings?  We could do this at the cost of up to
2kB of memcpy whenever we switch mms.  Expensive but maybe not a
showstopper.

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web