| .. | .. |
|---|
| 15 | 15 | |
|---|
| 16 | 16 | /* |
|---|
| 17 | 17 | * __read_mostly is used to keep rarely changing variables out of frequently |
|---|
| 18 | | - * updated cachelines. If an architecture doesn't support it, ignore the |
|---|
| 19 | | - * hint. |
|---|
| 18 | + * updated cachelines. Its use should be reserved for data that is used |
|---|
| 19 | + * frequently in hot paths. Performance traces can help decide when to use |
|---|
| 20 | + * this. You want __read_mostly data to be tightly packed, so that in the |
|---|
| 21 | + * best case multiple frequently read variables for a hot path will be next |
|---|
| 22 | + * to each other in order to reduce the number of cachelines needed to |
|---|
| 23 | + * execute a critical path. We should be mindful and selective of its use. |
|---|
| 24 | + * ie: if you're going to use it please supply a *good* justification in your |
|---|
| 25 | + * commit log |
|---|
| 20 | 26 | */ |
|---|
| 21 | 27 | #ifndef __read_mostly |
|---|
| 22 | 28 | #define __read_mostly |
|---|
| .. | .. |
|---|
| 28 | 34 | * but may get written to during init, so can't live in .rodata (via "const"). |
|---|
| 29 | 35 | */ |
|---|
| 30 | 36 | #ifndef __ro_after_init |
|---|
| 31 | | -#define __ro_after_init __attribute__((__section__(".data..ro_after_init"))) |
|---|
| 37 | +#define __ro_after_init __section(".data..ro_after_init") |
|---|
| 32 | 38 | #endif |
|---|
| 33 | 39 | |
|---|
| 34 | 40 | #ifndef ____cacheline_aligned |
|---|