lkml.org 
[lkml]   [2005]   [Jul]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: IBM HDAPS things are looking up
    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/

    \
     
     \ /
      Last update: 2005-07-04 20:45    [W:4.765 / U:0.020 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site