This is a rather hypothetical question.
I only have limited knowledge about how the cpu cache works.
I know a cpu loads subsequent bytes into the cache.
Since a list uses pointers/indirection into random locations in memory, it has relatively bad locality compared to lets say vector or an array.
My question is: If I write an allocator where the data of all nodes is next to each other (via linear allocator), will this improve the cache loading? The indirection is still there but the data for the different nodes are in similar locations.
Yes and no, but leaning mostly toward no, at least if you use the list in a way that lets you get anything out of it.
The advantage of a linked list is the ability to insert and delete elements in the middle of the list in constant time (provided you already know the point where you're going to insert/delete).
If you allocate objects linearly and insert them into the list linearly and access them linearly, yes, you'll get an improvement in locality. The problem is that if you're going to use the data that way, you might as well just put it in a vector and be done with it.
If you do insertions and deletions at arbitrary positions in the list, even though you originally allocated the nodes in linear order, you quickly end up with the order of the list no longer matching the order of allocation. In this case, a custom allocator might still do a little good. At least the nodes in your list won't be mixed in with other data, so you might improve locality of reference at least a little. But the improvement from this is likely to be quite small, even at best.
So yes, you can get good locality under some circumstances--but those circumstances are basically that you never take advantage of the characteristic(s) of a list that make it useful in the first place.