lkml.org 
[lkml]   [2004]   [Feb]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: IO scheduler, queue depth, nr_requests


    Miquel van Smoorenburg wrote:

    >On Thu, 19 Feb 2004 23:52:32, Nick Piggin wrote:
    >
    >>
    >>Miquel van Smoorenburg wrote:
    >>
    >
    ...

    >>>Note that this is not an issue of '2 processes writing to 1 file', really.
    >>>It's one process and pdflush writing the same dirty pages of the same file.
    >>>
    >>pdflush is a process though, that's all that matters.
    >>
    >
    >I understand that when the two processes are unrelated, the patch as I
    >sent it will do the wrong thing.
    >
    >But the thing is, you get this:
    >
    >- "dd" process writes requests
    >- pdflush triggers to write dirty pages
    >- too many pages are dirty so "dd" blocks as well to write synchronously
    >- "dd" process triggers "queue full" but gets marked as "batching" so
    > can continue (get_request)
    >- pdflush tries to submit one bio and gets blocked (get_request_wait)
    >- "dd" continues, but that one bio from pdflush remains stuck for a while
    >
    >

    The batching logic can probably all be ripped out with per
    process limits. It's too complex anyway really.

    >That's stupid, that one bio from pdflush should really be allowed on
    >the queue, since "dd" is adding requests from the same source to it
    >anyway.
    >
    >

    But the whole reason it is getting blocked in the first place
    is because your controller is sucking up all your requests.
    The whole problem is not a problem if you use properly sized
    queues.

    I'm a bit surprised that it wasn't working well with a controller
    queue depth of 64 and 128 nr_requests. I'll give you a per process
    request limit patch to try in a minute.

    >Perhaps writes from pdflush should be handled differently to prevent
    >this specific case ?
    >
    >Say, if pdflush adds request #128, don't mark it as batching, but
    >let it block. The next process will be the one marked as batching
    >and can continue. If pdflush tries to add a request > 128, allow it,
    >but _then_ block it.
    >
    >Would something like that work ? Would it be a good idea to never mark
    >a pdflush process as batching, or would that have a negative impact
    >for some things ?
    >
    >

    It's hard to know. Maybe a better solution would be to allow pdflush
    to be exempt from the limits entirely as long as it tries not to write
    to congested queues (which is what it does)...

    -
    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 14:01    [W:0.038 / U:30.192 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site