tsc-deadline. Which cpus ?

[JulienDarc]

Hello,

I have hard time to find relevant informations concerning Tsc-Deadline (amd and intel specs, net..).
That feature would exactly fit my need though.

-> Which cpu families support it ?

Thanks

[Brendan]

Hi,

I have hard time to find relevant informations concerning Tsc-Deadline (amd and intel specs, net..).
That feature would exactly fit my need though.

-> Which cpu families support it ?

I'm not sure (if I had to guess I'd say "maybe Nehalem and newer, possibly excluding funky stuff like some Atoms and Quark, and with a slight delay before AMD released CPUs that support it").

Mostly; software should use CPUID to find out if its supported or not, then use it if its supported or use something else. This means that in 5 years time your code works on CPUs that currently don't exist, regardless of whether TSC deadline mode is deprecated or not. If your OS requires it (has no fall-back for CPUs that don't support it) then you'd test that it exists during boot and inform the user why the OS failed (e.g. "TSC deadline mode not supported on this CPU; boot aborted"); and document the requirements in the OS's documentation (e.g. "OS requires things, stuff, and TSC deadline mode"). What I'm hinting at here is that you probably shouldn't need to worry about which CPUs do/don't support it.


Cheers,

Brendan

[JulienDarc]

Hi Brendan,

While I certainly agree I plan to buy some used hardware to make a server to test my OS.
I want to be sure to get the cheapest/not the latest cpu as possible.

Nehalem you think?

Will ask the Intel forum

Bye
Thanks

Julien

[Brendan]

Hi,

While I certainly agree I plan to buy some used hardware to make a server to test my OS.

For full testing, you'd need to test all the combinations (Intel/AMD, with deadline mode, with "fixed rate" TSC, with HPET, ..., etc). This can get expensive if you're testing on real hardware and actually buy a computer for each different case; especially later when you start caring about many different CPU features.

The simple answer is to use a configurable virtual machine instead. Bochs is free (and does support TSC deadline).

Nehalem you think?

I tested on my Nehalem (Xeon E5520) with this code:

Code: Select all

int main(void) {
	int i;
	uint32_t a, b, c, d;

	i = 0;
	asm volatile ("cpuid" : "=a" (a), "=b" (b), "=c" (c), "=d" (d) : "a" (i), "c" (0));
	printf("0x%08X, 0x%08X, 0x%08X, 0x%08X\n", a,b,c,d);
	i = 1;
	asm volatile ("cpuid" : "=a" (a), "=b" (b), "=c" (c), "=d" (d) : "a" (i), "c" (0));
	printf("0x%08X, 0x%08X, 0x%08X, 0x%08X\n", a,b,c,d);
}

Results are:

Code: Select all

0x0000000B, 0x756E6547, 0x6C65746E, 0x49656E69
0x000106A5, 0x03100800, 0x009CE3BD, 0xBFEBFBFF

The "TSC deadline mode" feature flag is bit 24 of ECX, and this flag is clear, so (at least on my Nehalem) it's not supported. I don't have any Sandy Bridge or Ivy Bridge to test on; and I'd assume it's definitely supported on Haswell (and was too lazy to test on that).


Cheers,

Brendan

[Candy]

Code: Select all

0x0000000D, 0x756E6547, 0x6C65746E, 0x49656E69
0x000206A7, 0x06100800, 0x1FBAE3FF, 0xBFEBFBFF

From Intel(R) Core(TM) i7-2760QM CPU @ 2.40GHz, I think that's Sandy Bridge. Looks to be on.

I can test it on a Atom Z3735 too which I think is Ivy Bridge generation (and a hell of a lot cheaper) if you want.

[JulienDarc]

Thanks Brendan and Candy,

@Brendan : It can clearly get expensive but there is a hardware project behind.
I am used to use qemu though. I will look into it and conform to your advice Brendan.

@Candy : thanks do not bother for the atom, I will not be able to use it (massive calculations at times)

Edit :
The supported arch I target is amd64 only for the OS.
So, to be fully compatible my only option would be an array of timer and set lapic oneshots, as a fallback, right ? aren't oneshot timers too expensive to set up (will experiment, but if you have an upfront opinion)?

[Brendan]

Hi,

The supported arch I target is amd64 only for the OS.
So, to be fully compatible my only option would be an array of timer and set lapic oneshots, as a fallback, right ?

Normally (for time) you have some sort of sorted list (at least for things that will happen soon); and you set "the timer" to the shortest time. Note that "the timer" may be any of the following, where the main difference is precision:

• Local APIC in TSC deadline mode: typically nanosecond precision. Extremely hard to use if the TSC is not "fixed speed".
• Local APIC in one-shot mode mode: typically tens of nanoseconds precision
• HPET: typically hundreds of nanoseconds precision
• PIT: typically microsecond precision

For both local APIC modes there's one local APIC per CPU which can help a lot when you've got lots of CPUs. Also; on some CPUs the local APIC timer stops working when the CPU goes into certain low power states, which means you may have to shift things from the local APIC's list/s to some other timer's list/s (e.g. HPET, PIT) before entering the low power state (which means you still needs to support HPET and/or PIT anyway).

aren't oneshot timers too expensive to set up (will experiment, but if you have an upfront opinion)?

For overhead, it shouldn't make much difference - in both cases (after it's setup once during boot) you're just setting a "count" register.

However, TSC deadline mode is racey and you have to be very careful with "too short" periods of time. For example, you can calculate a new time by doing "now + 1234", but then an SMI will occur before you set the new count and 1234 cycles may have passed before the CPU returns from SMM and you set the count; and when that happens you won't get an IRQ until the TSC wraps around in about ~20 years. To guard against this you need to set the local APIC's count and then read the TSC to make sure you haven't already missed the deadline after its set (and then, if you think you have missed the deadline you don't know if the timer IRQ could've fired while you were checking). Of course all of this adds overhead, so TSC deadline mode probably has higher overhead than one-shot.


Cheers,

Brendan

[JulienDarc]

As usual Brendan,

I **really** thank you.
You are amazing.

Bye,

Julien