Menu
▾
▴
Re: [odin-os-devel] ATA delay talk
|
From: Chris R. <chr...@br...> - 2001-10-11 13:30:18
|
What was wrong with them?
ai...@li... wrote:
>
> Something seems to be wrong with replies from Chris, so I forward entire
> talk
>
> ------------------------------------------------------------------------
>
> Subject: Re: Re[2]: [odin-os-devel] Drivers
> Date: Wed, 10 Oct 2001 18:35:43 +0300
> From: ai...@li...
> To: berkus <odi...@li...>
>
> Yet more Q:
> When ATA driver resets the interface it should poll it for positive status
> for 31 seconds. There is no interrupt at the end of reset.
> Stupid endless reading of status register until timeout expires seems bad
> implementation for me, because lagre amount of CPU time (up to 31 second! )
> will be wasted on execution of high-priority thread.
> Is there any good way to implement this?
> Maybe driver initialization thread can lower its priority and enter this
> loop, then restore priority at the end? This way we can save some CPU time
> (not a big gain, but it's better than nothing).
>
> Any ideas on this are welcome.
> Igor
>
> ------------------------------------------------------------------------
>
> Subject: Re: [odin-os-devel] Drivers
> Date: Wed, 10 Oct 2001 16:00:39 +0100
> From: "Chris Randall" <chr...@br...>
> To: ai...@li...
> CC: berkus <odi...@li...>
> References: <200...@ns...>
>
> ai...@li... wrote:
> >
> > Yet more Q:
> > When ATA driver resets the interface it should poll it for positive status
> > for 31 seconds. There is no interrupt at the end of reset.
> > Stupid endless reading of status register until timeout expires seems bad
> > implementation for me, because lagre amount of CPU time (up to 31 second! )
> > will be wasted on execution of high-priority thread.
> > Is there any good way to implement this?
>
> Why not take a simple aproach;
>
> init ATA
> sleep(31)
> check status register.
>
> > Maybe driver initialization thread can lower its priority and enter this
> > loop, then restore priority at the end? This way we can save some CPU time
> > (not a big gain, but it's better than nothing).
> >
> > Any ideas on this are welcome.
> > Igor
>
> --
> Chris.
>
> ------------------------------------------------------------------------
>
> Subject: Re: [odin-os-devel] Drivers
> Date: Wed, 10 Oct 2001 17:24:00 +0100
> From: "Chris Randall" <chr...@br...>
> To: ai...@li...
> References: <200...@ns...>
>
> ai...@li... wrote:
> >
> > > ai...@li... wrote:
> > > >
> > > > Yet more Q:
> > > > When ATA driver resets the interface it should poll it for positive
> > status
> > > > for 31 seconds. There is no interrupt at the end of reset.
> > > > Stupid endless reading of status register until timeout expires seems
> > bad
> > > > implementation for me, because lagre amount of CPU time (up to 31
> > second! )
> > > > will be wasted on execution of high-priority thread.
> > > > Is there any good way to implement this?
> > >
> > > Why not take a simple aproach;
> > >
> > > init ATA
> > > sleep(31)
> > > check status register.
> > > Chris.
> >
> > Good, but if drive will become ready in, say, 10 msec and we'll wait for it
> > 31 sec - there's a little overhead, don't you think ?
> > Typically reset takes < 4 seconds (with normal modern drives from low-power
> > mode) or <1 sec if it is made from normal mode (I think driver should avoid
> > this)
>
> So why not:
>
> init ATA
> do {
> sleep(minimum_expected_time)
> device_ready = read device status;
> } while(!device_ready);
>
> So, you'll waste some time but probably little more than that's implied
> with dicking around with thread priorities, which presumably endup with
> a call via reschedule?
>
> --
> Chris.
>
> ------------------------------------------------------------------------
>
> Subject: Re: [odin-os-devel] Drivers
> Date: Wed, 10 Oct 2001 17:42:20 +0100
> From: "Chris Randall" <chr...@br...>
> To: ai...@li...
> References: <200...@ns...>
>
> You either do as I suggest and find a useful 'minimum expected time'
> through investigation, or as you suggest have a low priority thread
> running in the background. I guess a more interesting question to ask is
> how much other work can you do before the ATA is ready to do work ie.
> where does the rest of the OS reside, if it's on that disk what else can
> you do?
>
> ai...@li... wrote:
> >
> > Your suggestion is the most obvious way, but...
> > There's no minimum expected time in the standard!
> > If you have an idea about this time (when standard states nothing, we may
> > invent this statement ourselves), I wait for you suggestions.
> >
> > Igor
> > > ai...@li... wrote:
> > > >
> > > > > ai...@li... wrote:
> > > > > >
> > > > > > Yet more Q:
> > > > > > When ATA driver resets the interface it should poll it for positive
> > > > status
> > > > > > for 31 seconds. There is no interrupt at the end of reset.
> > > > > > Stupid endless reading of status register until timeout expires
> > seems
> > > > bad
> > > > > > implementation for me, because lagre amount of CPU time (up to 31
> > > > second! )
> > > > > > will be wasted on execution of high-priority thread.
> > > > > > Is there any good way to implement this?
> > > > >
> > > > > Why not take a simple aproach;
> > > > >
> > > > > init ATA
> > > > > sleep(31)
> > > > > check status register.
> > > > > Chris.
> > > >
> > > > Good, but if drive will become ready in, say, 10 msec and we'll wait
> > for it
> > > > 31 sec - there's a little overhead, don't you think ?
> > > > Typically reset takes < 4 seconds (with normal modern drives from
> > low-power
> > > > mode) or <1 sec if it is made from normal mode (I think driver should
> > avoid
> > > > this)
> > >
> > > So why not:
> > >
> > > init ATA
> > > do {
> > > sleep(minimum_expected_time)
> > > device_ready = read device status;
> > > } while(!device_ready);
> > >
> > > So, you'll waste some time but probably little more than that's implied
> > > with dicking around with thread priorities, which presumably endup with
> > > a call via reschedule?
> > >
> > > --
> > > Chris.
>
> --
> Chris.
>
> ------------------------------------------------------------------------
>
> Subject: Re: [odin-os-devel] Drivers
> Date: Wed, 10 Oct 2001 17:53:11 +0100
> From: "Chris Randall" <chr...@br...>
> To: ai...@li...
> References: <200...@ns...>
>
> What does the rest of the world do?
>
> ai...@li... wrote:
> >
> > If the OS is on that disk, than I can do simple stupid polling loop,
> > because there's nothing we can do.
> > But there may be other components already loaded with that driver and they
> > may do something useful.
> > Even more: sometimes reset maybe needed not only during boot-up (interface
> > reset is the only way of waking a drive from deepest power-down mode)
> >
> > Igor
> >
> > > You either do as I suggest and find a useful 'minimum expected time'
> > > through investigation, or as you suggest have a low priority thread
> > > running in the background. I guess a more interesting question to ask is
> > > how much other work can you do before the ATA is ready to do work ie.
> > > where does the rest of the OS reside, if it's on that disk what else can
> > > you do?
> > >
> > >
> > > ai...@li... wrote:
> > > >
> > > > Your suggestion is the most obvious way, but...
> > > > There's no minimum expected time in the standard!
> > > > If you have an idea about this time (when standard states nothing, we
> > may
> > > > invent this statement ourselves), I wait for you suggestions.
> > > >
> > > > Igor
> > > > > ai...@li... wrote:
> > > > > >
> > > > > > > ai...@li... wrote:
> > > > > > > >
> > > > > > > > Yet more Q:
> > > > > > > > When ATA driver resets the interface it should poll it for
> > positive
> > > > > > status
> > > > > > > > for 31 seconds. There is no interrupt at the end of reset.
> > > > > > > > Stupid endless reading of status register until timeout expires
> > > > seems
> > > > > > bad
> > > > > > > > implementation for me, because lagre amount of CPU time (up to
> > 31
> > > > > > second! )
> > > > > > > > will be wasted on execution of high-priority thread.
> > > > > > > > Is there any good way to implement this?
> > > > > > >
> > > > > > > Why not take a simple aproach;
> > > > > > >
> > > > > > > init ATA
> > > > > > > sleep(31)
> > > > > > > check status register.
> > > > > > > Chris.
> > > > > >
> > > > > > Good, but if drive will become ready in, say, 10 msec and we'll
> > wait
> > > > for it
> > > > > > 31 sec - there's a little overhead, don't you think ?
> > > > > > Typically reset takes < 4 seconds (with normal modern drives from
> > > > low-power
> > > > > > mode) or <1 sec if it is made from normal mode (I think driver
> > should
> > > > avoid
> > > > > > this)
> > > > >
> > > > > So why not:
> > > > >
> > > > > init ATA
> > > > > do {
> > > > > sleep(minimum_expected_time)
> > > > > device_ready = read device status;
> > > > > } while(!device_ready);
> > > > >
> > > > > So, you'll waste some time but probably little more than that's
> > implied
> > > > > with dicking around with thread priorities, which presumably endup
> > with
> > > > > a call via reschedule?
> > > > >
> > > > > --
> > > > > Chris.
> > >
> > > --
> > > Chris.
>
> --
> Chris.
>
> ------------------------------------------------------------------------
>
> Subject: Re[2]: [odin-os-devel] Drivers
> Date: Thu, 11 Oct 2001 12:00:12 +0600
> From: "Stanislav Karchebny" <be...@vi...>
> Reply-To: berkus <odi...@li...>
> Organization: visual mechanics
> To: alar <odi...@li...>
> References: <200...@ns...>
> <3BC...@br...>
>
> >> Is there any good way to implement this?
>
> CR> Why not take a simple aproach;
>
> CR> init ATA
> CR> sleep(31)
> CR> check status register.
>
> Good idea. However, ATA may finish its resetting before 31 seconds
> expire and waiting that much can be frustrating for user (e.g. during
> bootup). A modification of this approach would be to check status
> register each 5 or 3 seconds or even each 1 second - this way not much
> cpu time is wasted and response time is adequate.
>
> -- keep in touch. Stanislav Karchebny.
> * be...@vi... * http://ber.k45.ru * ICQ UIN 49516372 *
> * Odin operating system development: http://odin-os.sf.net *
> * Components down to the metal *
--
Chris.
|
