lkml.org 
[lkml]   [2003]   [Jun]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] io stalls
    On Thu, Jun 12, 2003 at 01:20:44PM +1000, Nick Piggin wrote:
    > Its no less fair this way, tasks will still be woken in fifo
    > order. They will just be given the chance to submit a batch
    > of requests.

    If you change the behaviour with queued_task_nr > batch_requests it is
    less fair period. Whatever else thing I don't care about right now
    because it is a minor cpu improvement anyways.

    I'm not talking about performance, I'm talking about latency and
    fariness only. This is the whole point of the ->full logic.

    > I think the cpu utilization gain of waking a number of tasks
    > at once would be outweighed by advantage of waking 1 task
    > and not putting it to sleep again for a number of requests.
    > You obviously are not claiming concurrency improvements, as
    > your method would also increase contention on the io lock
    > (or the queue lock in 2.5).

    I'm claiming that with queued_task_nr > batch_requests the
    batch_requests logic still has a chance to save some cpu, this is the
    only reason I didn't nuke it completely as you suggested some email ago.

    > Then you have the cache gains of running each task for a
    > longer period of time. You also get possible IO scheduling
    > improvements.
    >
    > Consider 8 requests, batch_requests at 4, 10 tasks writing
    > to different areas of disk.
    >
    > Your method still only allows each task to have 1 request in
    > the elevator at once. Mine allows each to have a run of 4
    > requests in the elevator.

    I definitely want 1 request in the elevator at once or we can as well
    drop your ->full and return to be unfair. The whole point of ->full is
    to get the total fariness, across the tasks in the queue queue, and for
    tasks outside the queue calling get_request too. Since not all tasks
    will fit in the I/O queue, providing a very fair FIFO in the
    wait_for_request is fundamental to provide any sort of latency
    guarantee IMHO (the fact an _exclusive wakeup removal that mixes stuff
    and probably has the side effect of being more fair, made that much
    difference to mainline users kind of confirms that).

    Andrea
    -
    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-03-22 13:36    [W:0.032 / U:30.356 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site