On Mon, Jul 27, 2020 at 2:54 PM Martin Liška wrote:
>
> On 7/27/20 2:51 PM, Richard Biener wrote:
> > On Mon, Jul 27, 2020 at 2:50 PM Andreas Schwab
> > wrote:
> >>
> >> On Jul 27 2020, Martin Liška wrote:
> >>
> >>> @Andreas: Is it a known issue?
> >>
> >> Which issue?
> >
> > I guess Martin me
On 7/27/20 2:51 PM, Richard Biener wrote:
On Mon, Jul 27, 2020 at 2:50 PM Andreas Schwab wrote:
On Jul 27 2020, Martin Liška wrote:
@Andreas: Is it a known issue?
Which issue?
I guess Martin means the checking glibc done looks excessive
(for the specific case of realloc). But yes, it's e
On Mon, Jul 27, 2020 at 2:50 PM Andreas Schwab wrote:
>
> On Jul 27 2020, Martin Liška wrote:
>
> > @Andreas: Is it a known issue?
>
> Which issue?
I guess Martin means the checking glibc done looks excessive
(for the specific case of realloc). But yes, it's enabled in the build roots
so we just
On Jul 27 2020, Martin Liška wrote:
> @Andreas: Is it a known issue?
Which issue?
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
On Mon, Jul 27, 2020 at 1:24 PM Martin Liška wrote:
>
> On 7/27/20 1:11 PM, Jan Hubicka wrote:
> >> On 7/27/20 9:11 AM, Richard Biener wrote:
> >>> OK. I guess the previous code tried to use less memory.
> >>
> >> It did. But I didn't realize that such exact growth would lead
> >> to a massive re
On 7/27/20 1:11 PM, Jan Hubicka wrote:
On 7/27/20 9:11 AM, Richard Biener wrote:
OK. I guess the previous code tried to use less memory.
It did. But I didn't realize that such exact growth would lead
to a massive reallocation for huge apps like chromium.
I would consider it an API issue - i
On 7/27/20 1:03 PM, Jan Hubicka wrote:
Did you do chroot to the chromium build?
Oh, you are right!
It really takes move than 60 seconds with:
35.43% a.outlibc-2.31.so [.] mem2chunk_check
26.54% a.outlibc-2.31.so [.] mem2mem_check
21.50% a.outlibc-2.31.so
> On 7/27/20 9:11 AM, Richard Biener wrote:
> > OK. I guess the previous code tried to use less memory.
>
> It did. But I didn't realize that such exact growth would lead
> to a massive reallocation for huge apps like chromium.
I would consider it an API issue - it is not really at all that obvi
On Mon, Jul 27, 2020 at 12:48 PM Jan Hubicka wrote:
>
> > Yes, I verified that.
> >
> > > I guess I can try
> > > to do some profiling since this problem did not show on Firefox (that i
> > > find odd given that Firefox is just about half of the size).
> >
> > Yep, I'm also surprised about it.
> >
> It runs for me in:
>
> $ time ./a.out 10
>
> real 0m10.048s
> user 0m9.742s
> sys 0m0.305s
Did you do chroot to the chromium build?
>
> Note that there may be an interleaving load on the machine.
> Perf says:
>
> 55.40% a.outlibc-2.26.so [.] realloc
> 36.01% a.
On 7/27/20 12:48 PM, Jan Hubicka wrote:
Yes, I verified that.
I guess I can try
to do some profiling since this problem did not show on Firefox (that i
find odd given that Firefox is just about half of the size).
Yep, I'm also surprised about it.
Perhaps glibc has some stupid limit in reall
> Yes, I verified that.
>
> > I guess I can try
> > to do some profiling since this problem did not show on Firefox (that i
> > find odd given that Firefox is just about half of the size).
>
> Yep, I'm also surprised about it.
>
> > Perhaps glibc has some stupid limit in realloc that makes it to
On 7/27/20 11:51 AM, Jan Hubicka wrote:
On 7/27/20 9:11 AM, Richard Biener wrote:
OK. I guess the previous code tried to use less memory.
It did. But I didn't realize that such exact growth would lead
to a massive reallocation for huge apps like chromium.
I'm going to backport the patch olde
> On 7/27/20 9:11 AM, Richard Biener wrote:
> > OK. I guess the previous code tried to use less memory.
>
> It did. But I didn't realize that such exact growth would lead
> to a massive reallocation for huge apps like chromium.
>
> I'm going to backport the patch older releases as well.
Thank y
On 7/27/20 9:11 AM, Richard Biener wrote:
OK. I guess the previous code tried to use less memory.
It did. But I didn't realize that such exact growth would lead
to a massive reallocation for huge apps like chromium.
I'm going to backport the patch older releases as well.
Martin
On Sat, Jul 25, 2020 at 2:23 PM Martin Liška wrote:
>
> Hello.
>
> When inserting into fast_call_summary (or fast_function_summary), we grow
> a vector to a _exact_ size based on cgraph_max_summary_id or
> edges_max_summary_id.
> Problem is that it causes very many reallocation and we should rath
16 matches
Mail list logo
