x/sys/cpu: add type CacheLinePad

[AlexRouSg]

#24843 added a new package for CPU feature detection, when looking through the package I noticed const cacheLineSize and thought that could be useful if it were exported.

My use case is the same as the package, adding padding to structs to prevent false sharing.

[tklauser]

/cc @bradfitz @ianlancetaylor

I think it'd be fine to export cacheLineSize in x/sys/cpu.

[martisch]

If these are exported i suggest to add a warning in the documentation that these are best effort guesses based on GOARCH and might not be the cpus actual cache line size.

They shouldn't be used anywhere where their correctness matters for the programs correctness to avoid issues like:
http://www.mono-project.com/news/2016/09/12/arm64-icache/

[mundaym]

C++17 introduced std::hardware_{constructive,destructive}_interference_size, it might be worth considering a similar approach if we are exposing the API:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0154r1.html

[ianlancetaylor]

Like @martisch, I think it's problematic to export cacheLineSize as a constant. It's not the same on different processors with the same GOARCH value.

I would be OK with exporting it as a variable if we can arrange to set the variable correctly.

[AlexRouSg]

@ianlancetaylor How about instead of a const CacheLineSize there's a type Pad [cacheLineSize]byte so it's clear the intended usage is only to add padding to structs.

[ianlancetaylor]

An array type doesn't sound very flexible, as it doesn't permit adjusting the padding to be only what is required to avoid cache contention.

A constant like MaxCacheLineSize would be OK with me.

[AlexRouSg]

Regarding the var CacheLineSize, Intel's cpuid package has this implemented for x86 so maybe this would be useful as a reference.

https://github.com/intel-go/cpuid

[gopherbot]

Change https://golang.org/cl/111775 mentions this issue: cpu: export cache line size

[mundaym]

I'm uncomfortable with the name MaxCacheLineSize. It could, for example, refer to the L2 cache line size if that is larger than the L1 cache line size.

Since the only use case identified so far is to avoid false sharing I think we should use a name like DestructiveIntereferenceSize, FalseSharingSize, SharedInterferenceSize or similar. This would also allow us to increase it if there are architectural quirks, such as cache line prefetching, that make it desirable to pad (and maybe align in Go 2) data structures to more than the cache line size.

[rsc]

Calling it CacheLineSize or MaxCacheLineSize does seem to promise more than we need and maybe more than we can deliver.

Would it be enough to introduce:

type CacheLinePad [64]byte

appropriately sized for each system, and leave it at that? At least then it's clear what it's for, and people would be discouraged from using it for other things.

Still doesn't seem particularly clean but maybe this is just not something we can do cleanly.

[tklauser]

In #25203 (comment) @ianlancetaylor mentioned that an array type might be a bit too inflexible. I also see @mundaym's and @rsc's point about the name being ambiguous and/or promising something we can't deliver.

I think renaming the const to either DestructiveIntereferenceSize, FalseSharingSize, SharedInterferenceSize might make less of a promise while still allowing a certain kind of flexibility. What do you think?

[AlexRouSg]

Since I made the proposal thought I'd give my opinions.

I don't really care what you guys call it, but I do see the benefit of a const over a type which allows fine tuning the padding e.g.

type foo struct {
    _ [cpu.CacheLineSize]byte
    x, y, z int
    _ [cpu.CacheLineSize - 24]byte
}

I'm not too sure what's the use case of a var but since @ianlancetaylor brought it up maybe he knows of one?

[ianlancetaylor]

A const is fine with me as long as it's clear that it represents the maximum cache line size of a particular architecture. And, of course, it may change over time. I was thinking of a var because within a single architecture different processors have different cache line sizes. But since the main use seems to be for struct padding, a var is not helpful.

An array type is more awkward than a const in some cases but is perhaps more clear for the intended use. The array type can still be used in the same way as the const by calling len.