[lkml]   [2005]   [Mar]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRE: [patch] optimization: defer bio_vec deallocation
    > Dave Jones wrote on Monday, March 28, 2005 7:00 PM
    > > If you can't publish results from that certain benchmark due its stupid
    > > restrictions,

    Forgot to thank Dave earlier for his understanding. I can't even mention the
    4 letter acronym for the benchmark. Sorry, I did not make the rule nor have
    the power to change the rule.

    Jens Axboe wrote on Tuesday, March 29, 2005 12:13 AM
    > Just _some_ results would be nice, Dave is right in that 'measurable
    > gains' doesn't really say anything at all. Personally I would like to
    > see a profile diff, for instance. And at least something like 'we get 1%
    > gain bla bla'.

    OK, performance gain for this industry db benchmark is 0.3%.

    > Now, about the patch. I cannot convince myself that it is not deadlock
    > prone, if someone waits for a bvec to be freed. Will slab reclaim always
    > prune the bio slab and push the bvecs back into the mempool, or can
    > there be cases where this doesn't happen?

    So on allocation, I should always get memory from slab first, if fail then
    get from mempool. Mark the bvec appropriately where the memory came from.
    On deallocating bio, check bvec flag and return memory if they came from
    mempool. Would that address your concern?

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-04-06 13:31    [W:0.019 / U:20.220 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site