Re: IBM HDAPS things are looking up

[Jens Axboe <axboe@suse.de>]

On Mon, Jul 04 2005, Alejandro Bonilla wrote:
> Jens Axboe wrote:
> 
> >
> >That's madness, we can't add a kernel thread for every single little
> >silly thing. You don't need to stop any io, you just want to make sure
> >that your park request gets issued right after the current io has
> >finished.
> > 
> >
> HI,
> 
>    For me, the heads have to park so fast. That I would be afraid of a 
> kernel panil or something that could happen if you park the head so fast 
> that it won't even tell the kernel it did, or because ext3 couldn't 
> update or any crazy reason.
> 
>    I use a lot a project called laptop_mode, which suspend the hd until 
> you do a request to the kernel or the HD and it spins up the HD. I think 
> somehow, the kernel is not fast enough to do what we want, I mean, I 
> don't see it.
> 
>    Imagine you are in starbucks, your laptop is over a 1.2 M table, 
> Linus just said that a new kernel is out. So you simply download it, and 
> now you are compiling it. But, you invited your kid to Starbucks. And 
> while your CPU is at 100% and full throttle HD usage. Then your kid 
> trips on the cable or simply pushes the PC out.
> 
>    Do you think that the kernel will STOP, HOLD and park the head in 
> less than a second? OR on the time we need?
> 
>    I would say is a dammed good kernel if it would. (could RTOS, make 
> things faster)
> 
> Simply send the flames my way if you think I'm totally wrong. Which I 
> might be. I really don't know...

You have to wait for the current command to finish, that is the fastest
approach. Aborting it would likely take longer. So what I describe
above, is really as fast as you can issue that command. If you are busy
doing io (writes, from the sound of the above), a single command doesn't
take very long as it goes to cache. Lets just say 10ms as a nice
pessimistic number. On average, that means you have 5ms until that
command finishes and you can issue the park. Submitting the park command
doesn't take long, the time is dominated by the actual park time. Which
is hardware bound, there's not much we can improve there in software.

The actualy accel daemon would run at an appropriate scheduling
priority/class, to ensure good response there.

-- 
Jens Axboe

-
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/