Interrupt latency on x86 platform.

Hi all,

on x86 systems is there any known side effect on interrupt latency caused by
string instructions?

Regards,
Maurizio Rossi

Maurizio Rossi <mrossi@system-group.it> wrote:

Hi all,

on x86 systems is there any known side effect on interrupt latency caused by
string instructions?

Depends on what you mean by a side-effect. How big?

And, what do you mean by “string instructions”?

Assuming you mean string functions, e.g. strcpy, strdup,…

strdup() could cause an allocation, which could cause a kernel call, and
the interrupt latency would be different whether the system is in-kernel
or in-process. But, both are normal states to take an interrupt in, and
it should not have a major side-effect.

Are the string functions being called inside an interrupt handler?

Anything done in one interrupt handler can affect another.

Are the string functions being done with interrupts disabled? Then,
the longer they take, the more it will affect things. And, some of
them (e.g. strdup) could restore interrupts as a side-effect. This
would have the side-effect of reducing interrupt latency.

-David

QNX Training Services
http://www.qnx.com/services/training/
Please followup in this newsgroup if you have further questions.

Hi David,

I was referring to string instructions available on x86 cpus (rep movsw…)
and not to string functions.

Regards,
Maurizio Rossi


“David Gibbs” <dagibbs@qnx.com> ha scritto nel messaggio
news:f00gn0$ame$1@nntp.qnx.com

Maurizio Rossi <> mrossi@system-group.it> > wrote:
Hi all,

on x86 systems is there any known side effect on interrupt latency caused
by
string instructions?

Depends on what you mean by a side-effect. How big?

And, what do you mean by “string instructions”?

Assuming you mean string functions, e.g. strcpy, strdup,…

strdup() could cause an allocation, which could cause a kernel call, and
the interrupt latency would be different whether the system is in-kernel
or in-process. But, both are normal states to take an interrupt in, and
it should not have a major side-effect.

Are the string functions being called inside an interrupt handler?

Anything done in one interrupt handler can affect another.

Are the string functions being done with interrupts disabled? Then,
the longer they take, the more it will affect things. And, some of
them (e.g. strdup) could restore interrupts as a side-effect. This
would have the side-effect of reducing interrupt latency.

-David

QNX Training Services
http://www.qnx.com/services/training/
Please followup in this newsgroup if you have further questions.

Maurizio Rossi <mrossi@system-group.it> wrote:

Hi David,

I was referring to string instructions available on x86 cpus (rep movsw…)
and not to string functions.

Ah, ok. For those, I don’t THINK so, but don’t know for sure.

-David

Regards,
Maurizio Rossi



“David Gibbs” <> dagibbs@qnx.com> > ha scritto nel messaggio
news:f00gn0$ame$> 1@nntp.qnx.com> …
Maurizio Rossi <> mrossi@system-group.it> > wrote:
Hi all,

on x86 systems is there any known side effect on interrupt latency caused
by
string instructions?

Depends on what you mean by a side-effect. How big?

And, what do you mean by “string instructions”?

Assuming you mean string functions, e.g. strcpy, strdup,…

strdup() could cause an allocation, which could cause a kernel call, and
the interrupt latency would be different whether the system is in-kernel
or in-process. But, both are normal states to take an interrupt in, and
it should not have a major side-effect.

Are the string functions being called inside an interrupt handler?

Anything done in one interrupt handler can affect another.

Are the string functions being done with interrupts disabled? Then,
the longer they take, the more it will affect things. And, some of
them (e.g. strdup) could restore interrupts as a side-effect. This
would have the side-effect of reducing interrupt latency.

-David

QNX Training Services
http://www.qnx.com/services/training/
Please followup in this newsgroup if you have further questions.


QNX Training Services
http://www.qnx.com/services/training/
Please followup in this newsgroup if you have further questions.