asm::delay blocks for 1.5 times longer on 0.6.5

interrupt::disable();
let mut p = defmt::unwrap!(cortex_m::Peripherals::take());
p.DCB.enable_trace();
p.DWT.enable_cycle_counter();
let start = DWT::get_cycle_count();
cortex_m::asm::delay(1_000_000);
let end = DWT::get_cycle_count();

defmt::info!("{:?}", end - start);

This snippet prints 1_500_000 with cortex-m 0.6.5 but 1_000_000 with cortex-m 0.6.4

Behavior observed on both the nRF52840 and the STM32L433.

I personally consider this to be a breaking change.
The API doc does say that function blocks for "at least" N clock cycles but I would the function at worst to be off by some constant/arithmetic factor (+k) not by a geometric factor (*k).

And I would only expect that arithmetic factor in presence of interrupts.

I'm aware that delay can be off by a geometric factor is there's Flash latency but that's not what observed above: Flash configuration was not changed; only the cortex-m version was.

Start by locating the implementation of cortex_m::asm::delay and compare its behavior between cortex-m 0.6.4 and 0.6.5. Reproduce the cycle-count measurement on the nRF52840 or STM32L433 using the issue's snippet. Done means the delay no longer exhibits the reported 1.5x change without a documented reason.