[#86787] [Ruby trunk Feature#14723] [WIP] sleepy GC — ko1@...

Issue #14723 has been updated by ko1 (Koichi Sasada).

13 messages 2018/05/01
[#86790] Re: [Ruby trunk Feature#14723] [WIP] sleepy GC — Eric Wong <normalperson@...> 2018/05/01

[email protected] wrote:

[#87095] [Ruby trunk Feature#14767] [PATCH] gc.c: use monotonic counters for objspace_malloc_increase — ko1@...

Issue #14767 has been updated by ko1 (Koichi Sasada).

9 messages 2018/05/17
[#87096] Re: [Ruby trunk Feature#14767] [PATCH] gc.c: use monotonic counters for objspace_malloc_increase — Eric Wong <normalperson@...> 2018/05/17

[email protected] wrote:

[ruby-core:87211] Re: [Ruby trunk Feature#14759] [PATCH] set M_ARENA_MAX for glibc malloc

From: Eric Wong <normalperson@...>
Date: 2018-05-21 06:30:10 UTC
List: ruby-core #87211
[email protected] wrote:
> I tried to change Mike's script to use I/O, and I've created a
> script that works best with glibc with no MALLOC_ARENA_MAX
> specified.

Interesting, you found a corner case of some fixed sizes where
the glibc default appears the best.

I tested 16K instead of 64K since my computer is too slow
and 16K is the default buffer size for IO.copy_stream,
net/protocol, etc...) and the default was still best
in that case.

So, I wonder if there is a trim threshold where this happens
and multiple arenas tickles the threshold more frequently.

However, I believe Mike's script of random sizes is more
representative of realistic memory use.  Unfortunately,
srand+rand alone is not enough to give consistently reproducible
results for benchmarking with threads...

Maybe a single thread needs to generate all the random numbers
and feed them round-robin to per-thread SizedQueue for
deterministic results.

Unsubscribe: <mailto:[email protected]?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>

In This Thread

Prev Next