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

Groups > linux.kernel > #1249331 > unrolled thread

Re: [RFC] perf: fix building for ARCv1

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: [RFC] perf: fix building for ARCv1 Vineet Gupta <Vineet.Gupta1@synopsys.com> - 2015-10-17 16:20 +0200
    Re: [RFC] perf: fix building for ARCv1 Alexey Brodkin <Alexey.Brodkin@synopsys.com> - 2015-10-18 13:20 +0200
      Re: [RFC] perf: fix building for ARCv1 Andi Kleen <andi@firstfloor.org> - 2015-10-19 01:20 +0200
        Re: [RFC] perf: fix building for ARCv1 Vineet Gupta <Vineet.Gupta1@synopsys.com> - 2015-10-19 07:00 +0200
          Re: [RFC] perf: fix building for ARCv1 Andi Kleen <andi@firstfloor.org> - 2015-10-19 08:00 +0200
            Re: [RFC] perf: fix building for ARCv1 Vineet Gupta <Vineet.Gupta1@synopsys.com> - 2015-10-19 11:30 +0200
              Re: [RFC] perf: fix building for ARCv1 Peter Zijlstra <peterz@infradead.org> - 2015-10-19 11:40 +0200
                Re: [RFC] perf: fix building for ARCv1 Vineet Gupta <Vineet.Gupta1@synopsys.com> - 2015-10-19 11:50 +0200
                  Re: [RFC] perf: fix building for ARCv1 Peter Zijlstra <peterz@infradead.org> - 2015-10-19 12:00 +0200
                    Re: [RFC] perf: fix building for ARCv1 Vineet Gupta <Vineet.Gupta1@synopsys.com> - 2015-10-19 12:10 +0200
                    Re: [RFC] perf: fix building for ARCv1 Vineet Gupta <Vineet.Gupta1@synopsys.com> - 2015-10-20 10:10 +0200
                      Re: [RFC] perf: fix building for ARCv1 Peter Zijlstra <peterz@infradead.org> - 2015-10-20 12:20 +0200
                        Re: [RFC] perf: fix building for ARCv1 Vineet Gupta <Vineet.Gupta1@synopsys.com> - 2015-10-20 12:50 +0200
                          Re: [RFC] perf: fix building for ARCv1 Alexey Brodkin <Alexey.Brodkin@synopsys.com> - 2015-10-29 17:00 +0100
                            Re: [RFC] perf: fix building for ARCv1 Vineet Gupta <Vineet.Gupta1@synopsys.com> - 2015-10-30 07:30 +0100

#1249331 — Re: [RFC] perf: fix building for ARCv1

On Saturday 17 October 2015 07:06 PM, Alexey Brodkin wrote:
> Perf uses atomic options and so it is required to have atomics enabled
> in toolchain.
>
> In case of ARC atomics are enabled by default for ARCv2 but disabled for
> ARCv1. Now we explicitly enable atomics for either ARC achitecture
> version so perf could be successfully built.
>
> Currently on attempt to build perf for ARCv1 you'll see tons of:
> ----------------->8-----------------
> undefined reference to `__sync_add_and_fetch_4'
> ----------------->8-----------------
>
> Still note if ARCv1 CPU is configured without LL/SC perf will crash on
> execution once "llock" instruction is attempted to be executed.

Ok this fixes ARCompact - assuming it will have LL/SC. We do have old SoCs w/o
that support.
So what we are saying is that any arch (or a configuration thereof) which doesn't
support atomic r-m-w can't even build perf now - that sucks !

A better way would be to do feature test for __sync_xyz and make atomic_xxx
wrappers call __sync_xyz) vs. an empty stub.
So atleast such arches can build and do "some" perf work !

-Vineet

> Cc: Vineet Gupta <vgupta@synopsys.com>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
> Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
> ---
>  tools/perf/config/Makefile | 5 +++++
>  1 file changed, 5 insertions(+)
>
> diff --git a/tools/perf/config/Makefile b/tools/perf/config/Makefile
> index 38a0853..dc7c0a8 100644
> --- a/tools/perf/config/Makefile
> +++ b/tools/perf/config/Makefile
> @@ -47,6 +47,11 @@ ifeq ($(ARCH),arm64)
>    LIBUNWIND_LIBS = -lunwind -lunwind-aarch64
>  endif
>  
> +# Additional ARCH settings for ARC
> +ifeq ($(ARCH),arc)
> +  CFLAGS += -matomic
> +endif
> +
>  ifeq ($(NO_PERF_REGS),0)
>    $(call detected,CONFIG_PERF_REGS)
>  endif

--
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]

#1250113

SGkgVmluZWV0LA0KDQpMb29rcyBsaWtlIHRoaXMgdGltZSBhdG9taWNzIGFyZSBhIG11c3QuIEFu
ZCB0aGF0IHJlYWxseSBzdWNrcyENCg0KU2VlIHRoZXNlIGNvbW1pdHMgdGhhdCBpbnRyb2R1Y2Ug
dXNhZ2Ugb2YgYXRvbWljX3h4eCgpIGFsbCBhcm91bmQgdGhlIHBlcmYgYW5kIHRvb2xzIGl0IHVz
ZXM6DQpodHRwOi8vZ2l0Lmtlcm5lbC5vcmcvY2dpdC9saW51eC9rZXJuZWwvZ2l0L3RvcnZhbGRz
L2xpbnV4LmdpdC9jb21taXQvP2lkPWY4MTJkMzA0NWMyMzg1YWMxNjIzN2U2OGIxNTY4NTljNDAw
NTUyNmUNCmh0dHA6Ly9naXQua2VybmVsLm9yZy9jZ2l0L2xpbnV4L2tlcm5lbC9naXQvdG9ydmFs
ZHMvbGludXguZ2l0L2NvbW1pdC8/aWQ9ZDNhN2M0ODljN2ZkMjQ2M2UzYjJjM2EyMTc5YzdiZTg3
OWRkOWNiNA0KaHR0cDovL2dpdC5rZXJuZWwub3JnL2NnaXQvbGludXgva2VybmVsL2dpdC90b3J2
YWxkcy9saW51eC5naXQvY29tbWl0Lz9pZD03MTQzODQ5YTVkNmE1YzYyM2Q4MTc5MGQ5MmYwMDMz
NTA3YzViMTRmDQpodHRwOi8vZ2l0Lmtlcm5lbC5vcmcvY2dpdC9saW51eC9rZXJuZWwvZ2l0L3Rv
cnZhbGRzL2xpbnV4LmdpdC9jb21taXQvP2lkPTU5YTUxYzFkYzlmYmIzZmI0YWY5MjhiODUyZDdi
MzVkZjgzZWRkNzQNCmh0dHA6Ly9naXQua2VybmVsLm9yZy9jZ2l0L2xpbnV4L2tlcm5lbC9naXQv
dG9ydmFsZHMvbGludXguZ2l0L2NvbW1pdC8/aWQ9ZTFlZDNhNWI4N2VkNjc1OWUxNmVjOTNmMTZh
YWU4M2QyY2M3N2NhMg0KDQphbmQgdGhhdCdzIHRoZSBvbmUgdGhhdCBpbnRyb2R1Y2VkIHVzYWdl
IG9mIHRoZSBmb2xsb3dpbmcgZ2VuZXJpYyBnY2MncyBhdG9taWNzDQooX19zeW5jX2FkZF9hbmRf
ZmV0Y2gvX19zeW5jX3N1Yl9hbmRfZmV0Y2gpOg0KaHR0cDovL2dpdC5rZXJuZWwub3JnL2NnaXQv
bGludXgva2VybmVsL2dpdC90b3J2YWxkcy9saW51eC5naXQvY29tbWl0Lz9pZD1kYTZkODU2NzUx
MmRmMTFlMDQ3M2I3MTBjMDdkZTg3ZWZkZTU3MDljDQoNClNvIHRoZSBiZXN0IHdlIG1heSBkbyBp
cyB0byBpbXBsZW1lbnQgZGV0ZWN0aW9uIG9mIGF0b21pY3MgaW4gdGhlIHRvb2xjaGFpbiBhbmQg
aWYgdGhlcmUncyBubyBhdG9taWNzIGhhcmQgc3RvcCB3aXRoDQpwZXJmIGJ1aWxkaW5nLg0KDQot
QWxleGV5DQoNCk9uIFNhdCwgMjAxNS0xMC0xNyBhdCAxNDoxOSArMDAwMCwgVmluZWV0IEd1cHRh
IHdyb3RlOg0KPiBPbiBTYXR1cmRheSAxNyBPY3RvYmVyIDIwMTUgMDc6MDYgUE0sIEFsZXhleSBC
cm9ka2luIHdyb3RlOg0KPiA+IFBlcmYgdXNlcyBhdG9taWMgb3B0aW9ucyBhbmQgc28gaXQgaXMg
cmVxdWlyZWQgdG8gaGF2ZSBhdG9taWNzIGVuYWJsZWQNCj4gPiBpbiB0b29sY2hhaW4uDQo+ID4g
DQo+ID4gSW4gY2FzZSBvZiBBUkMgYXRvbWljcyBhcmUgZW5hYmxlZCBieSBkZWZhdWx0IGZvciBB
UkN2MiBidXQgZGlzYWJsZWQgZm9yDQo+ID4gQVJDdjEuIE5vdyB3ZSBleHBsaWNpdGx5IGVuYWJs
ZSBhdG9taWNzIGZvciBlaXRoZXIgQVJDIGFjaGl0ZWN0dXJlDQo+ID4gdmVyc2lvbiBzbyBwZXJm
IGNvdWxkIGJlIHN1Y2Nlc3NmdWxseSBidWlsdC4NCj4gPiANCj4gPiBDdXJyZW50bHkgb24gYXR0
ZW1wdCB0byBidWlsZCBwZXJmIGZvciBBUkN2MSB5b3UnbGwgc2VlIHRvbnMgb2Y6DQo+ID4gLS0t
LS0tLS0tLS0tLS0tLS0+OC0tLS0tLS0tLS0tLS0tLS0tDQo+ID4gdW5kZWZpbmVkIHJlZmVyZW5j
ZSB0byBgX19zeW5jX2FkZF9hbmRfZmV0Y2hfNCcNCj4gPiAtLS0tLS0tLS0tLS0tLS0tLT44LS0t
LS0tLS0tLS0tLS0tLS0NCj4gPiANCj4gPiBTdGlsbCBub3RlIGlmIEFSQ3YxIENQVSBpcyBjb25m
aWd1cmVkIHdpdGhvdXQgTEwvU0MgcGVyZiB3aWxsIGNyYXNoIG9uDQo+ID4gZXhlY3V0aW9uIG9u
Y2UgImxsb2NrIiBpbnN0cnVjdGlvbiBpcyBhdHRlbXB0ZWQgdG8gYmUgZXhlY3V0ZWQuDQo+IA0K
PiBPayB0aGlzIGZpeGVzIEFSQ29tcGFjdCAtIGFzc3VtaW5nIGl0IHdpbGwgaGF2ZSBMTC9TQy4g
V2UgZG8gaGF2ZSBvbGQgU29DcyB3L28NCj4gdGhhdCBzdXBwb3J0Lg0KPiBTbyB3aGF0IHdlIGFy
ZSBzYXlpbmcgaXMgdGhhdCBhbnkgYXJjaCAob3IgYSBjb25maWd1cmF0aW9uIHRoZXJlb2YpIHdo
aWNoIGRvZXNuJ3QNCj4gc3VwcG9ydCBhdG9taWMgci1tLXcgY2FuJ3QgZXZlbiBidWlsZCBwZXJm
IG5vdyAtIHRoYXQgc3Vja3MgIQ0KPiANCj4gQSBiZXR0ZXIgd2F5IHdvdWxkIGJlIHRvIGRvIGZl
YXR1cmUgdGVzdCBmb3IgX19zeW5jX3h5eiBhbmQgbWFrZSBhdG9taWNfeHh4DQo+IHdyYXBwZXJz
IGNhbGwgX19zeW5jX3h5eikgdnMuIGFuIGVtcHR5IHN0dWIuDQo+IFNvIGF0bGVhc3Qgc3VjaCBh
cmNoZXMgY2FuIGJ1aWxkIGFuZCBkbyAic29tZSIgcGVyZiB3b3JrICENCj4gDQo+IC1WaW5lZXQN
Cj4gDQo+ID4gQ2M6IFZpbmVldCBHdXB0YSA8dmd1cHRhQHN5bm9wc3lzLmNvbT4NCj4gPiBDYzog
UGV0ZXIgWmlqbHN0cmEgPHBldGVyekBpbmZyYWRlYWQub3JnPg0KPiA+IENjOiBBcm5hbGRvIENh
cnZhbGhvIGRlIE1lbG8gPGFjbWVAa2VybmVsLm9yZz4NCj4gPiBTaWduZWQtb2ZmLWJ5OiBBbGV4
ZXkgQnJvZGtpbiA8YWJyb2RraW5Ac3lub3BzeXMuY29tPg0KPiA+IC0tLQ0KPiA+ICB0b29scy9w
ZXJmL2NvbmZpZy9NYWtlZmlsZSB8IDUgKysrKysNCj4gPiAgMSBmaWxlIGNoYW5nZWQsIDUgaW5z
ZXJ0aW9ucygrKQ0KPiA+IA0KPiA+IGRpZmYgLS1naXQgYS90b29scy9wZXJmL2NvbmZpZy9NYWtl
ZmlsZSBiL3Rvb2xzL3BlcmYvY29uZmlnL01ha2VmaWxlDQo+ID4gaW5kZXggMzhhMDg1My4uZGM3
YzBhOCAxMDA2NDQNCj4gPiAtLS0gYS90b29scy9wZXJmL2NvbmZpZy9NYWtlZmlsZQ0KPiA+ICsr
KyBiL3Rvb2xzL3BlcmYvY29uZmlnL01ha2VmaWxlDQo+ID4gQEAgLTQ3LDYgKzQ3LDExIEBAIGlm
ZXEgKCQoQVJDSCksYXJtNjQpDQo+ID4gICAgTElCVU5XSU5EX0xJQlMgPSAtbHVud2luZCAtbHVu
d2luZC1hYXJjaDY0DQo+ID4gIGVuZGlmDQo+ID4gIA0KPiA+ICsjIEFkZGl0aW9uYWwgQVJDSCBz
ZXR0aW5ncyBmb3IgQVJDDQo+ID4gK2lmZXEgKCQoQVJDSCksYXJjKQ0KPiA+ICsgIENGTEFHUyAr
PSAtbWF0b21pYw0KPiA+ICtlbmRpZg0KPiA+ICsNCj4gPiAgaWZlcSAoJChOT19QRVJGX1JFR1Mp
LDApDQo+ID4gICAgJChjYWxsIGRldGVjdGVkLENPTkZJR19QRVJGX1JFR1MpDQo+ID4gIGVuZGlm
DQo+IA0KPiA=
--
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]

#1250257

Alexey Brodkin <Alexey.Brodkin@synopsys.com> writes:
>
> So the best we may do is to implement detection of atomics in the toolchain and if there's no atomics hard stop with
> perf building.

If your target is single cpu only you can always simulate them in C.

-Andi
--
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]

#1250330

On Monday 19 October 2015 04:45 AM, Andi Kleen wrote:
> Alexey Brodkin <Alexey.Brodkin@synopsys.com> writes:
>> So the best we may do is to implement detection of atomics in the toolchain and if there's no atomics hard stop with
>> perf building.
> If your target is single cpu only you can always simulate them in C.
>
> -Andi

But this user space - so IMHO UP/SMP doesn't matter and we can't simulate them in
C just by itself.

-Vineet
--
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]

#1250355

Vineet Gupta <Vineet.Gupta1@synopsys.com> writes:
>
> But this user space - so IMHO UP/SMP doesn't matter and we can't simulate them in
> C just by itself.

It matters when you access the perf ring buffer which is updated by kernel.
Also perf is now multi threaded to some degree.

-Andi
--
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]

#1250500

On Monday 19 October 2015 11:20 AM, Andi Kleen wrote:
> Vineet Gupta <Vineet.Gupta1@synopsys.com> writes:
>> But this user space - so IMHO UP/SMP doesn't matter and we can't simulate them in
>> C just by itself.
> It matters when you access the perf ring buffer which is updated by kernel.

That's part of the problem. The issue is with atomic_* APIs proliferation in perf
user space code which assumes native atomix r-m-w support which is not always
true. So I think we still need a feature detection mechanism and if absent leave
the ball in arch court by calling arch_atomic_* which can use creative or half
working measures so perf will work to some extent atleast and not bomb outright.

Also can u please elaborate a bit on "simulate them in C" - u mean just simple
unprotected LD, OP, ST or do u fancy usage of futex etc?

> Also perf is now multi threaded to some degree.


--
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]

#1250519

On Mon, Oct 19, 2015 at 09:28:43AM +0000, Vineet Gupta wrote:
> On Monday 19 October 2015 11:20 AM, Andi Kleen wrote:
> > Vineet Gupta <Vineet.Gupta1@synopsys.com> writes:
> >> But this user space - so IMHO UP/SMP doesn't matter and we can't simulate them in
> >> C just by itself.
> > It matters when you access the perf ring buffer which is updated by kernel.
> 
> That's part of the problem. The issue is with atomic_* APIs proliferation in perf
> user space code which assumes native atomix r-m-w support which is not always
> true. So I think we still need a feature detection mechanism and if absent leave
> the ball in arch court by calling arch_atomic_* which can use creative or half
> working measures so perf will work to some extent atleast and not bomb outright.
> 
> Also can u please elaborate a bit on "simulate them in C" - u mean just simple
> unprotected LD, OP, ST or do u fancy usage of futex etc?

Doesn't ARMv5 have a cmpxchg syscall to deal with this? It does an
IRQ-disabled load-op-store sequence.


--
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]

#1250522

On Monday 19 October 2015 03:05 PM, Peter Zijlstra wrote:
> On Mon, Oct 19, 2015 at 09:28:43AM +0000, Vineet Gupta wrote:
>> > On Monday 19 October 2015 11:20 AM, Andi Kleen wrote:
>>> > > Vineet Gupta <Vineet.Gupta1@synopsys.com> writes:
>>>> > >> But this user space - so IMHO UP/SMP doesn't matter and we can't simulate them in
>>>> > >> C just by itself.
>>> > > It matters when you access the perf ring buffer which is updated by kernel.
>> > 
>> > That's part of the problem. The issue is with atomic_* APIs proliferation in perf
>> > user space code which assumes native atomix r-m-w support which is not always
>> > true. So I think we still need a feature detection mechanism and if absent leave
>> > the ball in arch court by calling arch_atomic_* which can use creative or half
>> > working measures so perf will work to some extent atleast and not bomb outright.
>> > 
>> > Also can u please elaborate a bit on "simulate them in C" - u mean just simple
>> > unprotected LD, OP, ST or do u fancy usage of futex etc?
> Doesn't ARMv5 have a cmpxchg syscall to deal with this? It does an
> IRQ-disabled load-op-store sequence.

Yeah I remember seeing some syscall like that in ARM.

On ARC we could use the atomic EXchange to implement a user space only binary
semaphore - these atomic ops will be small duration so it is OK to spin wait for a
little bit. That's how the old pthread library worked for ARC w/o any atomic support.

--
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]

#1250534

On Mon, Oct 19, 2015 at 09:46:35AM +0000, Vineet Gupta wrote:
> On ARC we could use the atomic EXchange to implement a user space only binary
> semaphore - these atomic ops will be small duration so it is OK to spin wait for a
> little bit. That's how the old pthread library worked for ARC w/o any atomic support.

That has the obvious problem of lock-holder-preemption and the horrible
performance issues that result from that.

I think the syscall at least has deterministic behaviour, whereas that
userspace spin loop has this abysmal worst case thing.
--
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]

#1250537

On Monday 19 October 2015 03:22 PM, Peter Zijlstra wrote:
> On Mon, Oct 19, 2015 at 09:46:35AM +0000, Vineet Gupta wrote:
>> > On ARC we could use the atomic EXchange to implement a user space only binary
>> > semaphore - these atomic ops will be small duration so it is OK to spin wait for a
>> > little bit. That's how the old pthread library worked for ARC w/o any atomic support.
> That has the obvious problem of lock-holder-preemption and the horrible
> performance issues that result from that.
>
> I think the syscall at least has deterministic behaviour, whereas that
> userspace spin loop has this abysmal worst case thing.

I agree - we can add that syscall trivially and use it based on build time feature
detection for atomics !
--
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]

#1251412

On Monday 19 October 2015 03:22 PM, Peter Zijlstra wrote:
> On Mon, Oct 19, 2015 at 09:46:35AM +0000, Vineet Gupta wrote:
>> On ARC we could use the atomic EXchange to implement a user space only binary
>> semaphore - these atomic ops will be small duration so it is OK to spin wait for a
>> little bit. That's how the old pthread library worked for ARC w/o any atomic support.
> That has the obvious problem of lock-holder-preemption and the horrible
> performance issues that result from that.
>
> I think the syscall at least has deterministic behaviour, whereas that
> userspace spin loop has this abysmal worst case thing.

I don't have issue with adding the syscall per-se. But that comes with it's own
headaches of ABI change - more importantly it requires several things to match,
libc, kernel...  It would be easier if change was confined to say perf.

Can we use existing syscall(s) - again this is what our good old pthread library
code did.

static void __pthread_acquire(int * spinlock)
{
  int cnt = 0;
  struct timespec tm;

  READ_MEMORY_BARRIER();

  while (testandset(spinlock)) {   <---- atomic EXchange
    if (cnt < 50) {
      sched_yield();
      cnt++;
    } else {
      tm.tv_sec = 0;
      tm.tv_nsec = 2000001;
      nanosleep(&tm, ((void *)0));
      cnt = 0;
    }
  }

--
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]

#1251567

On Tue, Oct 20, 2015 at 08:00:46AM +0000, Vineet Gupta wrote:
> On Monday 19 October 2015 03:22 PM, Peter Zijlstra wrote:
> > On Mon, Oct 19, 2015 at 09:46:35AM +0000, Vineet Gupta wrote:
> >> On ARC we could use the atomic EXchange to implement a user space only binary
> >> semaphore - these atomic ops will be small duration so it is OK to spin wait for a
> >> little bit. That's how the old pthread library worked for ARC w/o any atomic support.
> > That has the obvious problem of lock-holder-preemption and the horrible
> > performance issues that result from that.
> >
> > I think the syscall at least has deterministic behaviour, whereas that
> > userspace spin loop has this abysmal worst case thing.
> 
> I don't have issue with adding the syscall per-se. But that comes with it's own
> headaches of ABI change - more importantly it requires several things to match,
> libc, kernel...  It would be easier if change was confined to say perf.

OTOH fixing all those would get you a 'sane' system :-)

> Can we use existing syscall(s) - again this is what our good old pthread library
> code did.
> 
> static void __pthread_acquire(int * spinlock)
> {
>   int cnt = 0;
>   struct timespec tm;
> 
>   READ_MEMORY_BARRIER();
> 
>   while (testandset(spinlock)) {   <---- atomic EXchange
>     if (cnt < 50) {
>       sched_yield();
>       cnt++;
>     } else {
>       tm.tv_sec = 0;
>       tm.tv_nsec = 2000001;
>       nanosleep(&tm, ((void *)0));
>       cnt = 0;
>     }
>   }

*shudder* that is quite horrible.

This means all your 'atomics' are broken for anything SCHED_FIFO and the
like. You simply _cannot_ run a realtime system.

(also, for ACQUIRE you want the READ_MEMORY_BARRIER() _after_ the
test-and-set control dependency.)

But its your arch..
--
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]

#1251574

On Tuesday 20 October 2015 03:41 PM, Peter Zijlstra wrote:
>> > Can we use existing syscall(s) - again this is what our good old pthread library
>> > code did.
>> > 
>> > static void __pthread_acquire(int * spinlock)
>> > {
>> >   int cnt = 0;
>> >   struct timespec tm;
>> > 
>> >   READ_MEMORY_BARRIER();
>> > 
>> >   while (testandset(spinlock)) {   <---- atomic EXchange
>> >     if (cnt < 50) {
>> >       sched_yield();
>> >       cnt++;
>> >     } else {
>> >       tm.tv_sec = 0;
>> >       tm.tv_nsec = 2000001;
>> >       nanosleep(&tm, ((void *)0));
>> >       cnt = 0;
>> >     }
>> >   }
> *shudder* that is quite horrible.
>
> This means all your 'atomics' are broken for anything SCHED_FIFO and the
> like. You simply _cannot_ run a realtime system.

The code above is from uClibc old threading library which we don't use anymore.
The NPTL version doesn't have all of this song-n-dance and relies on futexes. The
change we are talking about is only for the atomics in perf itself. I do
understand your POV though.

> (also, for ACQUIRE you want the READ_MEMORY_BARRIER() _after_ the
> test-and-set control dependency.)

Absolutely and in this case it will have to be added both inside the loop and one
at the end to cover both the scenarios !

--
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]

#1258882

SGkgVmluZWV0LA0KDQpPbiBUdWUsIDIwMTUtMTAtMjAgYXQgMTA6NDUgKzAwMDAsIFZpbmVldCBH
dXB0YSB3cm90ZToNCj4gT24gVHVlc2RheSAyMCBPY3RvYmVyIDIwMTUgMDM6NDEgUE0sIFBldGVy
IFppamxzdHJhIHdyb3RlOg0KPiA+ID4gPiBDYW4gd2UgdXNlIGV4aXN0aW5nIHN5c2NhbGwocykg
LSBhZ2FpbiB0aGlzIGlzIHdoYXQgb3VyIGdvb2Qgb2xkIHB0aHJlYWQgbGlicmFyeQ0KPiA+ID4g
PiBjb2RlIGRpZC4NCj4gPiA+ID4gDQo+ID4gPiA+IHN0YXRpYyB2b2lkIF9fcHRocmVhZF9hY3F1
aXJlKGludCAqIHNwaW5sb2NrKQ0KPiA+ID4gPiB7DQo+ID4gPiA+ICAgaW50IGNudCA9IDA7DQo+
ID4gPiA+ICAgc3RydWN0IHRpbWVzcGVjIHRtOw0KPiA+ID4gPiANCj4gPiA+ID4gICBSRUFEX01F
TU9SWV9CQVJSSUVSKCk7DQo+ID4gPiA+IA0KPiA+ID4gPiAgIHdoaWxlICh0ZXN0YW5kc2V0KHNw
aW5sb2NrKSkgeyAgIDwtLS0tIGF0b21pYyBFWGNoYW5nZQ0KPiA+ID4gPiAgICAgaWYgKGNudCA8
IDUwKSB7DQo+ID4gPiA+ICAgICAgIHNjaGVkX3lpZWxkKCk7DQo+ID4gPiA+ICAgICAgIGNudCsr
Ow0KPiA+ID4gPiAgICAgfSBlbHNlIHsNCj4gPiA+ID4gICAgICAgdG0udHZfc2VjID0gMDsNCj4g
PiA+ID4gICAgICAgdG0udHZfbnNlYyA9IDIwMDAwMDE7DQo+ID4gPiA+ICAgICAgIG5hbm9zbGVl
cCgmdG0sICgodm9pZCAqKTApKTsNCj4gPiA+ID4gICAgICAgY250ID0gMDsNCj4gPiA+ID4gICAg
IH0NCj4gPiA+ID4gICB9DQo+ID4gKnNodWRkZXIqIHRoYXQgaXMgcXVpdGUgaG9ycmlibGUuDQo+
ID4gDQo+ID4gVGhpcyBtZWFucyBhbGwgeW91ciAnYXRvbWljcycgYXJlIGJyb2tlbiBmb3IgYW55
dGhpbmcgU0NIRURfRklGTyBhbmQgdGhlDQo+ID4gbGlrZS4gWW91IHNpbXBseSBfY2Fubm90XyBy
dW4gYSByZWFsdGltZSBzeXN0ZW0uDQo+IA0KPiBUaGUgY29kZSBhYm92ZSBpcyBmcm9tIHVDbGli
YyBvbGQgdGhyZWFkaW5nIGxpYnJhcnkgd2hpY2ggd2UgZG9uJ3QgdXNlIGFueW1vcmUuDQo+IFRo
ZSBOUFRMIHZlcnNpb24gZG9lc24ndCBoYXZlIGFsbCBvZiB0aGlzIHNvbmctbi1kYW5jZSBhbmQg
cmVsaWVzIG9uIGZ1dGV4ZXMuIFRoZQ0KPiBjaGFuZ2Ugd2UgYXJlIHRhbGtpbmcgYWJvdXQgaXMg
b25seSBmb3IgdGhlIGF0b21pY3MgaW4gcGVyZiBpdHNlbGYuIEkgZG8NCj4gdW5kZXJzdGFuZCB5
b3VyIFBPViB0aG91Z2guDQo+IA0KPiA+IChhbHNvLCBmb3IgQUNRVUlSRSB5b3Ugd2FudCB0aGUg
UkVBRF9NRU1PUllfQkFSUklFUigpIF9hZnRlcl8gdGhlDQo+ID4gdGVzdC1hbmQtc2V0IGNvbnRy
b2wgZGVwZW5kZW5jeS4pDQo+IA0KPiBBYnNvbHV0ZWx5IGFuZCBpbiB0aGlzIGNhc2UgaXQgd2ls
bCBoYXZlIHRvIGJlIGFkZGVkIGJvdGggaW5zaWRlIHRoZSBsb29wIGFuZCBvbmUNCj4gYXQgdGhl
IGVuZCB0byBjb3ZlciBib3RoIHRoZSBzY2VuYXJpb3MgIQ0KPiANCg0KSSdtIHdvbmRlcmluZyB3
aGF0IGFyZSBvdXIgcGxhbnMgZm9yIG5vdz8NCkFyZSB3ZSBnb2luZyB0byBhY2NlcHQgcHJvcG9z
ZWQgZml4IGp1c3QgZm9yIEFSQyBpbiA0LjQgKGFuZCB0byBhbGwgc3RhYmxlcyB0aGVuKQ0Kb3Ig
d2UnbGwgdHJ5IHRvIGNvbWUgdXAgd2l0aCBtb3JlIGdlbmVyYWwgc29sdXRpb24/DQoNCi1BbGV4
ZXk=
--
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]

#1259238

On Thursday 29 October 2015 09:28 PM, Alexey Brodkin wrote:
> Hi Vineet,
>
> On Tue, 2015-10-20 at 10:45 +0000, Vineet Gupta wrote:
>> On Tuesday 20 October 2015 03:41 PM, Peter Zijlstra wrote:
>>>>> Can we use existing syscall(s) - again this is what our good old pthread library
>>>>> code did.
>>>>>
>>>>> static void __pthread_acquire(int * spinlock)
>>>>> {
>>>>>   int cnt = 0;
>>>>>   struct timespec tm;
>>>>>
>>>>>   READ_MEMORY_BARRIER();
>>>>>
>>>>>   while (testandset(spinlock)) {   <---- atomic EXchange
>>>>>     if (cnt < 50) {
>>>>>       sched_yield();
>>>>>       cnt++;
>>>>>     } else {
>>>>>       tm.tv_sec = 0;
>>>>>       tm.tv_nsec = 2000001;
>>>>>       nanosleep(&tm, ((void *)0));
>>>>>       cnt = 0;
>>>>>     }
>>>>>   }
>>> *shudder* that is quite horrible.
>>>
>>> This means all your 'atomics' are broken for anything SCHED_FIFO and the
>>> like. You simply _cannot_ run a realtime system.
>> The code above is from uClibc old threading library which we don't use anymore.
>> The NPTL version doesn't have all of this song-n-dance and relies on futexes. The
>> change we are talking about is only for the atomics in perf itself. I do
>> understand your POV though.
>>
>>> (also, for ACQUIRE you want the READ_MEMORY_BARRIER() _after_ the
>>> test-and-set control dependency.)
>> Absolutely and in this case it will have to be added both inside the loop and one
>> at the end to cover both the scenarios !
>>
> I'm wondering what are our plans for now?
> Are we going to accept proposed fix just for ARC in 4.4 (and to all stables then)
> or we'll try to come up with more general solution?

I agree with the current solution to add -atomic to for arc700 builds.
Although making that default for arc700 tools will be better but that will not fix
things before next release of tools etc.

But we *do* need to improve generic solution
1. Add atomics detection in perf to add fall back arch stubs
2. ARC needs to add syscall for facilitating atomic r-m-w !

-Vineet
--
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