On Mar 17, 2:38 am, "Alexei A. Frounze" <spamt...@[EMAIL PROTECTED]
> wrote:
> On Mar 16, 4:02 pm, Stargazer <spamt...@[EMAIL PROTECTED]
> wrote:
>
>
>
>
>
> > Hi,
>
> > I am writing my own real-time kernel for x86. Now I face something
> > really strange (or may be rather it's not; it has been some time since
> > I was in the details of x86 microarchitecture).
>
> > I measured CPU clocks elapsed between the first assembly instruction
> > executed at interrupt's entry point in IDT and beginning of the C code
> > of user-defined interrupt handler and the result was a big
> > surprise :-) It took about 2500 cycles despite that I have only a
> > handful of assembly instructions before a call to user-supplied IRQ
> > handler.
>
> > A little more testing showed that almost all cycles (2300+) were spent
> > at access to a global variable (via ds:[] addressing). Nothing that
> > accesses stack memory (push, pop, call, mov) makes a noticeable
> > difference. Does anybody have an idea why this happens? I test on
> > Celeron 2.8G in protected mode set up for flat model with paging
> > disabled.
>
> > I can post the code of the interrupt's entry point (until the C entry
> > point is called), but it's rather trivial and not long.
>
> > Thanks,
> > D
>
> What are the min, max and average cycle counts (you need to repeat the
> measurement many times)?
> What are the numbers on other PCs?
A weird thing is that the difference between min and max is about 10
cycles. That is, results are fairly accurate and consistent.
I didn't test on other PCs yet.
> I wonder if it's SMIs. On my Dell Latitude D610 notebook an SMI (or a
> short burst of thereof) may take up to ~240K cycles, which is ~150
> microseconds at 1.6 GHz; on the old Compaq Armada 7800 notebook it's
> only 12K cycles or ~40 microseconds at 300 MHz. Hardware bugfixes and
> control are moving into the CPU. :(
I don't know. It's a single instruction that accounts for over 2000
cycles, I can point the instruction but don't understand the reason.
It's a read-modify-write (INC ds:[xxx]) and it has to do something
with the nature of instruction being RMW. Actually I have a BT ds:
[xxx] (read) several instructions before it, which doesn't cause
anything abnormal.
It sounds weird if SMI would somehow be triggered on each and any
hardware interrupt.
D
|
