https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71744
Florian Weimer changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71744
Florian Weimer changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71744
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71744
--- Comment #29 from Jakub Jelinek ---
Author: jakub
Date: Fri Sep 16 19:17:47 2016
New Revision: 240193
URL: https://gcc.gnu.org/viewcvs?rev=240193=gcc=rev
Log:
PR libgcc/71744
* unwind-dw2-fde.c (ATOMIC_FDE_FAST_PATH): Define
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71744
--- Comment #28 from torvald at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #20)
> (In reply to Gleb Natapov from comment #19)
> > (In reply to Jakub Jelinek from comment #18)
> > > (In reply to Gleb Natapov from comment #16)
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71744
--- Comment #27 from Gleb Natapov ---
(In reply to Jakub Jelinek from comment #26)
> (In reply to Gleb Natapov from comment #25)
> > Using Torvald's rwlock would be definitely better that current state, but
> > not as good as per thread lock.
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71744
--- Comment #26 from Jakub Jelinek ---
(In reply to Gleb Natapov from comment #25)
> Using Torvald's rwlock would be definitely better that current state, but
> not as good as per thread lock.
In theory there could be e.g. an option to keep
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71744
--- Comment #25 from Gleb Natapov ---
(In reply to Jakub Jelinek from comment #24)
> (In reply to Gleb Natapov from comment #23)
> > I am not sure I agree. 64 lock will take one page of memory, which is
> > negligible amount nowadays and we can
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71744
--- Comment #24 from Jakub Jelinek ---
(In reply to Gleb Natapov from comment #23)
> I am not sure I agree. 64 lock will take one page of memory, which is
> negligible amount nowadays and we can drop the array if compiled for single
> threaded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71744
--- Comment #23 from Gleb Natapov ---
(In reply to Jakub Jelinek from comment #20)
> (In reply to Gleb Natapov from comment #19)
> > (In reply to Jakub Jelinek from comment #18)
> > > (In reply to Gleb Natapov from comment #16)
> > > > Can you
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71744
--- Comment #22 from Gleb Natapov ---
(In reply to torvald from comment #21)
> (In reply to Jakub Jelinek from comment #17)
> > (In reply to torvald from comment #15)
> > > > Similarly, the 64 recursive locks in libc, again, significant amount
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71744
--- Comment #21 from torvald at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #17)
> (In reply to torvald from comment #15)
> > > Similarly, the 64 recursive locks in libc, again, significant amount of
> > > memory
> > > per process
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71744
--- Comment #20 from Jakub Jelinek ---
(In reply to Gleb Natapov from comment #19)
> (In reply to Jakub Jelinek from comment #18)
> > (In reply to Gleb Natapov from comment #16)
> > > Can you suggest an alternative to libgcc patch? Use other TLS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71744
--- Comment #19 from Gleb Natapov ---
(In reply to Jakub Jelinek from comment #18)
> (In reply to Gleb Natapov from comment #16)
> > Can you suggest an alternative to libgcc patch? Use other TLS model?
> > Allocate per thread storage dynamically
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71744
--- Comment #18 from Jakub Jelinek ---
(In reply to Gleb Natapov from comment #16)
> Can you suggest an alternative to libgcc patch? Use other TLS model?
> Allocate per thread storage dynamically somehow?
If we want to use TLS (which I hope we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71744
--- Comment #17 from Jakub Jelinek ---
(In reply to torvald from comment #15)
> > Similarly, the 64 recursive locks in libc, again, significant amount of
> > memory
> > per process that doesn't care about exceptions,
>
> That might be reducable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71744
--- Comment #16 from Gleb Natapov ---
Can you suggest an alternative to libgcc patch? Use other TLS model? Allocate
per thread storage dynamically somehow?
About lock array, I tries to use rwlock and the current one is not better than
regular
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71744
--- Comment #15 from torvald at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #14)
> Looking at that patchset, I just want to say that the use of TLS in libgcc
> is very much undesirable, it affects every program even when not using
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71744
--- Comment #14 from Jakub Jelinek ---
Looking at that patchset, I just want to say that the use of TLS in libgcc is
very much undesirable, it affects every program even when not using exceptions
(significant portion of them), especially when it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71744
--- Comment #13 from Gleb Natapov ---
I've done it with my version of it which does basically the same. The patch by
itself has no effect on scalability, but in conjunction with this fix for glibc
https://patchwork.ozlabs.org/patch/652301/ I get
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71744
--- Comment #12 from Jakub Jelinek ---
I'll bootstrap/regtest it today. That said, have you done any scalability
benchmarking with/without that patch?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71744
--- Comment #11 from Gleb Natapov ---
Jakub, can you apply your path please? As you've said glibc will also have to
be fixed and I am working on it, but without that patch fixing glibc will not
help either.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71744
Gleb Natapov changed:
What|Removed |Added
CC||gleb at scylladb dot com
--- Comment #10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71744
--- Comment #9 from Jakub Jelinek ---
Created attachment 38852
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38852=edit
gcc7-pr71744.patch
Untested patch for the old-style registry. But as long as glibc still takes a
global lock it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71744
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71744
--- Comment #7 from Andrew Pinski ---
Note the kernel has many of these locks too. Have you reported those cases to
them?
And yes I know about the number of cores increasing, trust me, I use a 96 (or
48 depending on if I am on single socket or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71744
--- Comment #6 from Andrew Pinski ---
(In reply to Nadav Har'El from comment #5)
> That is nothing more than an implementation bug.
Is it? The problem here is you need to start redesigning it to use lock-free
algorithms. I don't see a way of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71744
--- Comment #5 from Nadav Har'El ---
Some replies to Andrew's comments above:
1. As the number of cores continue to grow, libraries will also fix malloc
scalability issues, so concurrent malloc will no longer present a problem. The
code which
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71744
--- Comment #4 from Andrew Pinski ---
Also if you are using C++ features you need to understand scalibility issues
might not be under your control so you should stop using those features.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71744
--- Comment #3 from Andrew Pinski ---
This cache:
/* The unseen_objects list contains objects that have been registered
but not yet categorized in any way. The seen_objects list has had
its pc_begin and count fields initialized at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71744
Andrew Pinski changed:
What|Removed |Added
Component|libstdc++ |libgcc
--- Comment #2 from Andrew
31 matches
Mail list logo
