topology: Don't allocate on calls to span()

[Byte-Lab]

We're currently cloning cpumasks returned by calls to {Core, Cache, Node, Topology}::span(). If a caller needs to clone it, they can. Let's not penalize the callers that just want to query the underlying cpumask.

We might be able to further optimize -- the trait implementations for bitwise operations on Cpumasks don't take references on the rhs, so we're doing extra clones where we shouldn't need to. I also wasn't able to figure out how to iterate over the bits set in the underlying cpumask without using .into_iter(), which requires cloning as well.

[arighi]

Much better, with this change applied the overhead of re-creating the iterator every single time goes from 5.5% to 2.5% in scx_rustland.

It's still more efficient to cache the topology map in a Vec<> (as in #238), considering that the topology doesn't change (CPU hotplugging not supported yet). But I was wondering if I should implement that "caching" in topology crate, like providing a new TopologyMap object or similar, that can be potentially used by other schedulers as well, for a more efficient iteration across all the cores and CPUs...

For now this one LTGM, thanks!

[Byte-Lab]

Much better, with this change applied the overhead of re-creating the iterator every single time goes from 5.5% to 2.5% in scx_rustland.

It's still more efficient to cache the topology map in a Vec<> (as in #238), considering that the topology doesn't change (CPU hotplugging not supported yet). But I was wondering if I should implement that "caching" in topology crate, like providing a new TopologyMap object or similar, that can be potentially used by other schedulers as well, for a more efficient iteration across all the cores and CPUs...

For now this one LTGM, thanks!

Sure, sounds like it'd be useful!