* a bug in AS scheduler?
@ 2007-02-28 4:22 Xiaoning Ding
2007-02-28 12:10 ` Jens Axboe
0 siblings, 1 reply; 5+ messages in thread
From: Xiaoning Ding @ 2007-02-28 4:22 UTC (permalink / raw)
To: linux-kernel
Hi,
I am reading the source code AS scheduler in 2.6.18(as-ioscheduler.c).
In function as_close_req, variable delay is in millisecond, while
ad->antic_expire is in jiffies. Doesn't the comparison of delay and
ad->antic_expire make any problem?
The related source code is quoted blow:
if (ad->antic_status == ANTIC_OFF || !ad->ioc_finished)
delay = 0;
else
delay = ((jiffies - ad->antic_start) * 1000) / HZ;
if (delay == 0)
delta = 8192;
else if (delay <= 20 && delay <= ad->antic_expire)
delta = 8192 << delay;
else
return 1;
Xiaoning
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: a bug in AS scheduler?
2007-02-28 4:22 a bug in AS scheduler? Xiaoning Ding
@ 2007-02-28 12:10 ` Jens Axboe
2007-02-28 13:25 ` Benoit Boissinot
0 siblings, 1 reply; 5+ messages in thread
From: Jens Axboe @ 2007-02-28 12:10 UTC (permalink / raw)
To: Xiaoning Ding; +Cc: linux-kernel
On Tue, Feb 27 2007, Xiaoning Ding wrote:
> Hi,
>
> I am reading the source code AS scheduler in 2.6.18(as-ioscheduler.c).
> In function as_close_req, variable delay is in millisecond, while
> ad->antic_expire is in jiffies. Doesn't the comparison of delay and
> ad->antic_expire make any problem?
> The related source code is quoted blow:
>
> if (ad->antic_status == ANTIC_OFF || !ad->ioc_finished)
> delay = 0;
> else
> delay = ((jiffies - ad->antic_start) * 1000) / HZ;
antic_start is in jiffies, the difference is here multiplied by 1000 and
divided by HZ to turn it into msecs. so delay is in msecs.
--
Jens Axboe
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: a bug in AS scheduler?
2007-02-28 12:10 ` Jens Axboe
@ 2007-02-28 13:25 ` Benoit Boissinot
2007-02-28 13:34 ` Jens Axboe
0 siblings, 1 reply; 5+ messages in thread
From: Benoit Boissinot @ 2007-02-28 13:25 UTC (permalink / raw)
To: Jens Axboe; +Cc: Xiaoning Ding, linux-kernel
On 2/28/07, Jens Axboe <jens.axboe@oracle.com> wrote:
> On Tue, Feb 27 2007, Xiaoning Ding wrote:
> > Hi,
> >
> > I am reading the source code AS scheduler in 2.6.18(as-ioscheduler.c).
> > In function as_close_req, variable delay is in millisecond, while
> > ad->antic_expire is in jiffies. Doesn't the comparison of delay and
> > ad->antic_expire make any problem?
> > The related source code is quoted blow:
> >
> > if (ad->antic_status == ANTIC_OFF || !ad->ioc_finished)
> > delay = 0;
> > else
> > delay = ((jiffies - ad->antic_start) * 1000) / HZ;
>
> antic_start is in jiffies, the difference is here multiplied by 1000 and
> divided by HZ to turn it into msecs. so delay is in msecs.
>
I am pretty sure Xiaoning was talking about antic_expire, particularly
this comparison:
else if (delay <= 20 && delay <= ad->antic_expire)
regards,
Benoit
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: a bug in AS scheduler?
2007-02-28 13:25 ` Benoit Boissinot
@ 2007-02-28 13:34 ` Jens Axboe
2007-02-28 15:33 ` Xiaoning Ding
0 siblings, 1 reply; 5+ messages in thread
From: Jens Axboe @ 2007-02-28 13:34 UTC (permalink / raw)
To: Benoit Boissinot; +Cc: Xiaoning Ding, linux-kernel
On Wed, Feb 28 2007, Benoit Boissinot wrote:
> On 2/28/07, Jens Axboe <jens.axboe@oracle.com> wrote:
> >On Tue, Feb 27 2007, Xiaoning Ding wrote:
> >> Hi,
> >>
> >> I am reading the source code AS scheduler in 2.6.18(as-ioscheduler.c).
> >> In function as_close_req, variable delay is in millisecond, while
> >> ad->antic_expire is in jiffies. Doesn't the comparison of delay and
> >> ad->antic_expire make any problem?
> >> The related source code is quoted blow:
> >>
> >> if (ad->antic_status == ANTIC_OFF || !ad->ioc_finished)
> >> delay = 0;
> >> else
> >> delay = ((jiffies - ad->antic_start) * 1000) / HZ;
> >
> >antic_start is in jiffies, the difference is here multiplied by 1000 and
> >divided by HZ to turn it into msecs. so delay is in msecs.
> >
> I am pretty sure Xiaoning was talking about antic_expire, particularly
> this comparison:
>
> else if (delay <= 20 && delay <= ad->antic_expire)
Ah, I misread the name. That does look like a bug, antic_expire is in
jiffies.
--
Jens Axboe
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: a bug in AS scheduler?
2007-02-28 13:34 ` Jens Axboe
@ 2007-02-28 15:33 ` Xiaoning Ding
0 siblings, 0 replies; 5+ messages in thread
From: Xiaoning Ding @ 2007-02-28 15:33 UTC (permalink / raw)
To: Jens Axboe; +Cc: Benoit Boissinot, linux-kernel
Jens Axboe wrote:
> On Wed, Feb 28 2007, Benoit Boissinot wrote:
>> On 2/28/07, Jens Axboe <jens.axboe@oracle.com> wrote:
>>> On Tue, Feb 27 2007, Xiaoning Ding wrote:
>>>> Hi,
>>>>
>>>> I am reading the source code AS scheduler in 2.6.18(as-ioscheduler.c).
>>>> In function as_close_req, variable delay is in millisecond, while
>>>> ad->antic_expire is in jiffies. Doesn't the comparison of delay and
>>>> ad->antic_expire make any problem?
>>>> The related source code is quoted blow:
>>>>
>>>> if (ad->antic_status == ANTIC_OFF || !ad->ioc_finished)
>>>> delay = 0;
>>>> else
>>>> delay = ((jiffies - ad->antic_start) * 1000) / HZ;
>>> antic_start is in jiffies, the difference is here multiplied by 1000 and
>>> divided by HZ to turn it into msecs. so delay is in msecs.
>>>
>> I am pretty sure Xiaoning was talking about antic_expire, particularly
>> this comparison:
>>
>> else if (delay <= 20 && delay <= ad->antic_expire)
>
> Ah, I misread the name. That does look like a bug, antic_expire is in
> jiffies.
You got it.
Xiaoning
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2007-02-28 15:35 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-02-28 4:22 a bug in AS scheduler? Xiaoning Ding
2007-02-28 12:10 ` Jens Axboe
2007-02-28 13:25 ` Benoit Boissinot
2007-02-28 13:34 ` Jens Axboe
2007-02-28 15:33 ` Xiaoning Ding
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.