lkml.org 
[lkml]   [2006]   [Jan]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [patch 2/2] fix file counting
    "Paul E. McKenney" <paulmck@us.ibm.com> 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
    latencies?

    (And it forgot to initialise the atomic_t)

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

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