[lkml]   [2005]   [Oct]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: VFS: file-max limit 50044 reached

    On Mon, 17 Oct 2005, Eric Dumazet wrote:
    > <lazy_mode=ON>
    > Do we really need a TIF_RCUUPDATE flag, or could we just ask for a resched ?
    > </lazy_mode>

    Hmm.. Your patch looks very much like one I tried already, but the big
    difference being that I just cleared the count when doing the rcu
    callback. That was because I hadn't realized the importance of the
    maxbatch thing (so it didn't work for me, like it did for you).

    Still - the actual RCU callback will only be called at the next timer tick
    or whatever as far as I can tell, so the first time you'll still have a
    _long_ RCU queue (and thus bad latency).

    I guess that's inevitable - and TIF_RCUUPDATE wouldn't even help, because
    we still need to wait for the _other_ CPU's to get to their RCU quiescent

    However, that leaves us with the nasty situation that we'll ve very
    inefficient: we'll do "maxbatch" RCU entries, and then return, and then
    force a whole re-schedule. That just can't be good.

    How about instead of depending on "maxbatch", we'd depend on
    "need_resched()"? Mabe the "maxbatch" be a _minbatch_ thing, and then once
    we've done the minimum amount we _need_ to do (or emptied the RCU queue)
    we start honoring need_resched(), and return early if we do?

    That, together with your patch, should work, without causing ludicrous
    "reschedule every ten system calls" behaviour..


    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: 2009-11-18 23:46    [W:2.151 / U:0.108 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site