All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Borkmann <dborkman@redhat.com>
To: Tommi Rantala <tt.rantala@gmail.com>
Cc: trinity@vger.kernel.org, Dave Jones <davej@redhat.com>
Subject: Re: [PATCH 4/4] trinity: use Boehm-Demers-Weiser's garbage collecting memory allocator
Date: Thu, 13 Jun 2013 22:07:54 +0200	[thread overview]
Message-ID: <51BA269A.2040404@redhat.com> (raw)
In-Reply-To: <CA+ydwtrfNCfcbqb2GjgwZOaacChYjbkGD-nZH_gSjM5HWtS9fg@mail.gmail.com>

On 06/13/2013 08:57 PM, Tommi Rantala wrote:
> 2013/6/3 Daniel Borkmann <dborkman@redhat.com>:
>> trinity currently quite often does not care about freeing memory on
>> its own that was fetched through malloc(). Therefore it can happen if
>> trinity runs for quite a long time, that oom-killer gets invoked. So
>> for now use the Boehm-Demers-Weiser's garbage collecting memory
>> allocator as a malloc replacement to avoid such situations.
>>
>> In this patch, we wrap all BDW functions into bdw_* equivalents, so that
>> we could later on still #ifdef something if we want to and replace all
>> calls based on the build. Calling bdw_free() is still legimite although
>> not needed, but the memory is reclaimed automatically in the background
>> or forced via bdw_gcollect(), which would solve trinity's memory
>> management.
>>
>> Dependency that we need when building (in case people don't want
>> additional libs, follow-up patches could still #ifdef bdw_* wrappers
>> to the glibc functions):
>>
>>    Fedora: yum install gc-devel
>>
>>    Debian: apt-get install libgc-dev
>>
>> More information on Boehm-Demers-Weiser allocator can be found here:
>>
>>    http://www.hpl.hp.com/personal/Hans_Boehm/gc/
>>
>> Note that it is said that the performance is competitive with malloc(3),
>> free(3) calls.
>
> Thanks, tried this a bit.
>
> Based on a quick test, the performance impact is not acceptable.
>
> Vanilla trinity:
>
> $ timeout --signal=SIGINT 60 ./trinity -q -l off -C20
> [...]
> Ran 109049 syscalls. Successes: 20726  Failures: 88323
>
> Patch applied:
>
> $ timeout --signal=SIGINT 60 ./trinity-gc -q -l off -C20
> [...]
> Ran 17385 syscalls. Successes: 3073  Failures: 14312

Thanks for testing Tommi !

This does not look good and opposes the claim of the authors
pretty much.

Then I agree that we should drop this, and solve it otherwise,
e.g. via callback handlers that do some cleanup if necessary.

Cheers,

Daniel

      reply	other threads:[~2013-06-13 20:07 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-03 19:07 [PATCH 0/4] Enable seccomp generator and use Boehm-Demers-Weiser GC Daniel Borkmann
2013-06-03 19:07 ` [PATCH 1/4] net: bpf: let clang shut up Daniel Borkmann
2013-06-03 19:07 ` [PATCH 2/4] minor: move offsetof into trinity.h Daniel Borkmann
2013-06-03 19:07 ` [PATCH 3/4] prctl: enable seccomp generator invocation Daniel Borkmann
2013-06-03 19:07 ` [PATCH 4/4] trinity: use Boehm-Demers-Weiser's garbage collecting memory allocator Daniel Borkmann
2013-06-06 15:23   ` [PATCH] syscalls: use sizeof instead of hard code define Daniel Borkmann
2013-06-13 18:57   ` [PATCH 4/4] trinity: use Boehm-Demers-Weiser's garbage collecting memory allocator Tommi Rantala
2013-06-13 20:07     ` Daniel Borkmann [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=51BA269A.2040404@redhat.com \
    --to=dborkman@redhat.com \
    --cc=davej@redhat.com \
    --cc=trinity@vger.kernel.org \
    --cc=tt.rantala@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.