remove double store of deadline, saving 128 bytes

[conradludgate]

Motivation

Due to cache-aligned padding, Sleep is quite large.

Sleep totals 640 bytes, a majority of it is padding caused by CachePadded alignment.

Breakdown of cache usage

Breakdown of the size and padding made with help by @Nilstrieb using -Zprint-type-sizes

print-type-size type: `tokio::time::Sleep`: 640 bytes, alignment: 128 bytes
print-type-size     field `.entry`: 512 bytes
print-type-size     field `.inner`: 16 bytes
print-type-size     end padding: 112 bytes

print-type-size type: `tokio::runtime::time::entry::TimerEntry`: 512 bytes, alignment: 128 bytes
print-type-size     field `.driver`: 0 bytes
print-type-size     field `._m`: 0 bytes
print-type-size     field `.inner`: 384 bytes
print-type-size     field `.initial_deadline`: 16 bytes
print-type-size     end padding: 112 bytes

print-type-size type: `tokio::runtime::time::entry::TimerShared`: 384 bytes, alignment: 128 bytes
print-type-size     field `.driver_state`: 128 bytes
print-type-size     field `.state`: 256 bytes
print-type-size     field `._p`: 0 bytes

print-type-size type: `tokio::runtime::time::entry::StateCell`: 256 bytes, alignment: 128 bytes
print-type-size     field `.waker`: 128 bytes
print-type-size     field `.state`: 8 bytes
print-type-size     field `.result`: 1 bytes
print-type-size     end padding: 119 bytes

• CachePadded<StateCell::waker> has 104 bytes of padding.
• StateCell has 119 bytes of padding.
• CachePadded<TimerShared::driver_state> has 96 bytes of padding.
• TimerEntry has 112 bytes of padding.
• Sleep has 112 bytes of padding.

Total padding: 543 bytes.

This means in theory, Sleep should occupy no more than 128 bytes. In practice, I know this is more complicated, as the CachePadded decorators exist for a reason.

Solution

A simple fix is to utilise the initial_deadline field in the TimerEntry type, sharing it with Sleep. This cuts down on the outer layer of sleep needing 128 extra bytes.

Refs: #5348

[conradludgate]

I think in theory another 128 bytes of padding can be reasonably saved (under x86_64/aarch64 with 128bit padding for CachePadded). This requires inlining the TimerShared and StateCell into TimerEntry, which makes the intrusive linked list abstraction much harder to reason about.

[conradludgate]

History repeats itself #554

[Darksonn]

Please modify the PR description so that it keyword links to the issue this is related to.

[conradludgate]

Hmm. @Darksonn I guess it relates to #5348 but it doesn't fully resolve it. As mentioned in the issue we could completely remove the cache padding, but this PR does do that

[Darksonn]

Thanks.