Opened 8 years ago

Closed 9 months ago

#7420 closed bug (fixed)

Hoard allocator assumes wrong cache line size

Reported by: jonas.kirilla Owned by: nobody
Priority: normal Milestone: R1
Component: System/libroot.so Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All

Description

The cache line is assumed to be 32 bytes for i386 machines. Mine has 64 bytes/line.

http://haiku.it.su.se:8180/source/xref/src/system/libroot/posix/malloc/config.h#CACHE_LINE

It can supposedly lead to "false sharing". http://www.hoard.org/

Change History (7)

comment:1 by axeld, 8 years ago

As you can see, it's a hard coded value, and might not be that easy to fix. IIRC we had the intention to have a closer look at other allocators, anyway (since Hoard moved to the GPL, we cannot update it anyway, anymore -- last time I checked, nothing important happened there yet, though, but this was already a few years ago :-)).

comment:2 by tqh, 8 years ago

Could it be a GSoC task to evalute and create testcases, maybe even implement one or two for Haiku? It could also be done for memcpy and memmove cpu-module implementations, rep mov* is getting a bit dated.

comment:3 by tqh, 7 years ago

Some suggestions about malloc in #7009.

comment:4 by pulkomandy, 5 years ago

malloc alternatives:

Most benchmarks focus on performance, but we should also have a look at memory overhead and management of low-resource situation (it seems tcmalloc won't give memory back to the system in some cases for example).

comment:5 by axeld, 2 years ago

Owner: changed from axeld to nobody
Status: newassigned

comment:6 by waddlesplash, 9 months ago

Blocked By: 13554 added

comment:7 by waddlesplash, 9 months ago

Blocked By: 13554 removed
Resolution: fixed
Status: assignedclosed

"i386" is never defined, so the cache line is actually 64 on all systems.

Note: See TracTickets for help on using tickets.