Re: PREEMPT_RT vs I-PIPE: the numbers, part 2
From: Paul E. McKenney (paulmck_at_us.ibm.com)
Date: 06/22/05
- Previous message: Alexey Dobriyan: "Fwd: Re: [patch 1/3] __leify posix_acl_xattr_entry, posix_acl_xattr_header"
- In reply to: Karim Yaghmour: "Re: PREEMPT_RT vs I-PIPE: the numbers, part 2"
- Next in thread: Karim Yaghmour: "Re: PREEMPT_RT vs I-PIPE: the numbers, part 2"
- Reply: Karim Yaghmour: "Re: PREEMPT_RT vs I-PIPE: the numbers, part 2"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Wed, 22 Jun 2005 11:47:48 -0700 To: Karim Yaghmour <karim@opersys.com>
On Wed, Jun 22, 2005 at 01:58:46PM -0400, Karim Yaghmour wrote:
>
> Paul E. McKenney wrote:
> > I have big hands, so 7us could indeed qualify as a "handful".
>
> :)
>
> > Any insights as to what leads to the larger maximum delay? Some guesses
> > include worst-case cache-miss patterns and interrupt disabling that I
> > missed in my quick scan of the patch.
>
> Beats me. Given that PREEMPT_RT and the I-pipe get to the same maximum
> by using two entirely different approaches, I'm guessing this has more
> to do with hardware-related contention than anything inside the patches
> themselves.
Quite possible, perhaps worst-case cache state.
> > If I understand your analysis correctly (hah!!!), your breakdown
> > of the maximum delay assumes that the maximum delays for the logger
> > and the target are correlated. What causes this correlation?
>
> No it doesn't. I'm just inferring the maximum and average using the
> data obtained in the ipipe-to-ipipe setup. In that specific case,
> I'm assuming that the interrupt latency on both systems for the
> same type of interrupt is identical (after all, these machines are
> physically identical, albeit one has 512MB or RAM and the other
> 256.)
>
> There is no correlation. Just the assumption that what's actually
> being measured is twice the latency of the ipipe in that specific
> setup.
>
> Given that the interrupt latency of preempt_rt is measured using one
> machine runing adeos (read ipipe) and the other preempt_rt, I'm
> deducing the latency of preempt_rt based on the numbers obtained
> for the ipipe by looking at the ipipe-to-ipipe setup.
>
> > My (probably hopelessly naive) assumption would be that there would
> > be no such correlation. In absence of correlation, one might
> > approximate the maximum ipipe delay by subtracting the -average-
> > ipipe delay from the maximum preemption delay, for 55us - 7us = 48us.
> > Is this the case, or am I missing something here?
>
> Not directly. You'd have to start by saying that the true maximum ipipe
> delay is obtained by substracting the average ipipe delay from the
> measured maximum ipipe delay (to play safe you could even substract
> the minimum.)
>
> However such a maximum isn't correlated by the data. If indeed there
> was a difference between the maximums, averages and minimums of the
> ipipe and preempt_rt, the shear quantity of measurements would not
> have shown such latency similarities. IOW, it is expected that at
> least once in a blue moon we'll hit that case where both the target
> and the logger demonstrate their highest possible latency. That's
> what we can safely assume 55us is, again given the number of samples.
> Remember that on the first run, we sometimes observed a maximum
> ipipe-to-ipipe response time of 21us. That's because in those runs
> the blue-moon scenario didn't materialize.
Quite possible, depending on what the raw distribution of times looks
like. If there are a smallish number of 55us events (as there would
have to be given an average of 7us), the blue-moon scenario would lead
one to expect a much larger number of ~30us events (27.5us + 3.5us).
In absence of a ~30us bulge, there would still be the possibility that
one might see an even bluer (violet?) moon that might stack up to ~100us.
Heck, there might be that possibility anyway, but such is life when
measuring latencies. :-/
(And, yes, there are other CDFs lacking a 30us bulge that would be
consistent with a 55us "blue-moon" bulge -- so I guess I am asking
if you have the CDF or the raw latency measurements -- though the
data set might be a bit large... And I would have to think about
how one goes about deriving individual-latency CDF(s) given a single
dual-latency CDF, assuming that this is even possible...)
> > Of course, in the case of the -average- preemption measurements, dividing
> > by two to get the average ipipe delay makes perfect sense.
>
> There's no correlation, so I don't see this one.
You are right that there might not be a correlation, and that it might
be OK to just divide the maximum latency by two, but I can imagine
cases where dividing by two was not appropriate.
> > Whatever the answer to my maximum-delay question, the same breakdown of
> > the raw latency figures would apply to the CONFIG_PREEMPT_RT case, right?
>
> Sure, but again see the above caveats.
Thanks for the info!
Thanx, Paul
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
- Previous message: Alexey Dobriyan: "Fwd: Re: [patch 1/3] __leify posix_acl_xattr_entry, posix_acl_xattr_header"
- In reply to: Karim Yaghmour: "Re: PREEMPT_RT vs I-PIPE: the numbers, part 2"
- Next in thread: Karim Yaghmour: "Re: PREEMPT_RT vs I-PIPE: the numbers, part 2"
- Reply: Karim Yaghmour: "Re: PREEMPT_RT vs I-PIPE: the numbers, part 2"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
