Opened 9 years ago

Closed 17 months ago

Last modified 6 weeks ago

#7420 closed bug (fixed)

Hoard allocator assumes wrong cache line size

Reported by: jonas.kirilla Owned by: nobody
Priority: normal Milestone: R1/beta2
Component: System/ Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Platform: All


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

It can supposedly lead to "false sharing".

Change History (8)

comment:1 by axeld, 9 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, 9 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, 8 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, 3 years ago

Owner: changed from axeld to nobody
Status: newassigned

comment:6 by waddlesplash, 18 months ago

Blocked By: 13554 added

comment:7 by waddlesplash, 17 months ago

Blocked By: 13554 removed
Resolution: fixed
Status: assignedclosed

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

comment:8 by nielx, 6 weeks ago

Milestone: R1R1/beta2

Assign tickets with status=closed and resolution=fixed within the R1/beta2 development window to the R1/beta2 Milestone

Note: See TracTickets for help on using tickets.