Summary: | allow caches to be disabled for memory-constrained environments | ||
---|---|---|---|
Product: | dbus | Reporter: | Simon McVittie <smcv> |
Component: | core | Assignee: | Simon McVittie <smcv> |
Status: | RESOLVED MOVED | QA Contact: | D-Bus Maintainers <dbus> |
Severity: | enhancement | ||
Priority: | lowest | CC: | hp, msniko14 |
Version: | 1.5 | Keywords: | love |
Hardware: | All | ||
OS: | All | ||
Whiteboard: | |||
i915 platform: | i915 features: | ||
Attachments: |
Add a configure option to disable the message cache
Add a configure option to disable the DBusMemPool for linked-list links Add a configure option to disable DBusMemPool for hash table entries Replace vestigial efence support with --with-dbus-daemon-malloc |
Description
Simon McVittie
2011-03-07 10:33:29 UTC
Created attachment 44208 [details] [review] Add a configure option to disable the message cache The option is called "enable" even though the default is on, to avoid confusing people with double-negatives. Created attachment 44209 [details] [review] Add a configure option to disable the DBusMemPool for linked-list links Created attachment 44210 [details] [review] Add a configure option to disable DBusMemPool for hash table entries Created attachment 44211 [details] [review] Replace vestigial efence support with --with-dbus-daemon-malloc I've had good empirical results with jemalloc (aka FreeBSD malloc), which seems to be more effective at returning memory to the OS than glibc's modified ptmalloc2 while recovering from bus flooding. It does have more peak memory use, though, and slightly reduces throughput. Review of attachment 44208 [details] [review]: Looks fine to me. In the big picture one problem I see with autoconf options is they don't say *why* you may want them (or not want them). Linux kernel style config is nice here where each option gets a paragraph. Review of attachment 44209 [details] [review]: Hmm, is there a reason why one would want the message cache disabled but the linked list one enabled? Why not one global --disable-caches? Review of attachment 44211 [details] [review]: This one definitely could use a comment; so you now can do: --with-dbus-daemon-malloc=/usr/lib/libefence.so ? Maybe add "(path to shared library)" to the help description? From further testing, these might not actually be as effective as I'd hoped; more testing required, sadly. The reason I made them all separate was largely to be able to play with different settings without repeatedly adding/removing patches. (In reply to comment #7) > Review of attachment 44211 [details] [review]: > > This one definitely could use a comment; so you now can do: > > --with-dbus-daemon-malloc=/usr/lib/libefence.so > > ? Maybe add "(path to shared library)" to the help description? The help description does say "--with-dbus-daemon-malloc=[linker flags]"; the argument is added to LDADD. In practice I've been using something like --with-dbus-daemon-malloc=/home/smcv/.../libjemalloc_pic.a; if using a shared object, "-lefence" or "-L/opt/efence/lib -lefence" would be more appropriate. It's difficult to get a clear description in one line; perhaps we could do with a description in INSTALL. On the other hand, anyone contemplating using these option should probably be looking at the source code (and profiling the results) anyway... if there's an obvious right answer for any of them we should just make it the default. Not actively being worked on. One day someone should profile how much these caches actually help: it's possible that they're just unnecessary complexity. Comment on attachment 44208 [details] [review] Add a configure option to disable the message cache As of the merge of Bug #37286, the message cache can be disabled at runtime for memory-leak debugging, if DBUS_BUILD_TESTS is set. I'm not sure whether any of these make sense for purposes other than debugging memory leaks. -- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/dbus/dbus/issues/43. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.