[lkml]   [2006]   [Jan]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [patch 2/2] fix file counting
    "Paul E. McKenney" <> wrote:
    > > > I am using a patch that seems sligthly better : It removes the filp_count_lock
    > > > as yours but introduces a percpu variable, and a lazy nr_files . (Its value
    > > > can be off with a delta of +/- 16*num_possible_cpus()
    > >
    > > Yes, I think that is better.
    > I agree that Eric's approach likely improves performance on large systems
    > due to decreased cache thrashing. However, the real problem is getting
    > both good throughput and good latency in RCU callback processing, given
    > Lee Revell's latency testing results. Once we get that in hand, then
    > we should consider Eric's approach.

    Dipankar's patch risks worsening large-SMP scalability, doesn't it?
    Putting an atomic op into the file_free path?

    And afaict it fixes up the skew in the nr_files accounting but we're still
    exposed to the risk of large amounts of memory getting chewed up due to RCU

    (And it forgot to initialise the atomic_t)

    (And has a couple of suspicious-looking module exports. We don't support

    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: 2006-01-28 00:29    [W:0.021 / U:6.036 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site