lkml.org 
[lkml]   [2008]   [Feb]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [rfc] direct IO submission and completion scalability issues
    David Chinner wrote:
    > Hi Nick,
    >
    > When Matthew was describing this work at an LCA presentation (not
    > sure whether you were at that presentation or not), Zach came up
    > with the idea that allowing the submitting application control the
    > CPU that the io completion processing was occurring would be a good
    > approach to try. That is, we submit a "completion cookie" with the
    > bio that indicates where we want completion to run, rather than
    > dictating that completion runs on the submission CPU.
    >
    > The reasoning is that only the higher level context really knows
    > what is optimal, and that changes from application to application.

    well.. kinda. One of the really hard parts of the submit/completion stuff is that
    the slab/slob/slub/slib allocator ends up basically "cycling" memory through the system;
    there's a sink of free memory on all the submission cpus and a source of free memory
    on the completion cpu. I don't think applications are capable of working out what is
    best in this scenario..




    \
     
     \ /
      Last update: 2008-02-04 05:19    [W:0.023 / U:30.236 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site