On 17 September 2016 at 16:39, Joe Landman
<land...@scalableinformatics.com> wrote:
> On 09/17/2016 07:30 PM, Joshua M. Clulow wrote:
>> The SIGBUS you're seeing is potentially the result of our attempt to
>> get _some_ of the way toward overcommit, so that Linux software can
>> work even when it mistakenly assumes memory is an infinite resource.
> This said, SIGBUS is not usually memory allocation related ... this is more
> typically a memory alignment issue.  Google is your friend here.
> http://www.linuxprogrammingblog.com/all-about-linux-signals?page=4

I should probably have been more explicit.  My suggestion was in the
context of this discussion about LX branded zone environments, which
are Linux _compatible_, but not otherwise related to the Linux kernel.

Alignment issues are generally less common on x86 systems than on
other platforms, unless you're doing something unusual.  It's much
_more_ likely that a SIGBUS will arise _in an LX branded zone_ because
of swap cap exhaustion, because of the lack of memory over commit and
the implicit use of MAP_NORESERVE for mappings in LX processes.  It's
possible to confirm this by examining the fatal signal information
from a core file, if one was generated.

As Patrick notes, increasing the swap cap ("max_swap") for the zone is
likely to improve the situation for this workload.


Joshua M. Clulow
UNIX Admin/Developer

Archives: https://www.listbox.com/member/archive/184463/=now
RSS Feed: https://www.listbox.com/member/archive/rss/184463/25769125-55cfbc00
Modify Your Subscription: 
Powered by Listbox: http://www.listbox.com

Reply via email to