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
On Fri, Jan 27, 2006 at 02:54:12PM -0800, Andrew Morton wrote:
> Eric Dumazet <dada1@cosmosbay.com> wrote:
> >
> > > This patch changes the file counting by removing the filp_count_lock.
> > > Instead we use a separate atomic_t, nr_files, for now and all
> > > accesses to it are through get_nr_files() api. In the sysctl
> > > handler for nr_files, we populate files_stat.nr_files before returning
> > > to user.
> > >
> > > Counting files as an when they are created and destroyed (as opposed
> > > to inside slab) allows us to correctly count open files with RCU.
> > >
> > > Signed-off-by: Dipankar Sarma <dipankar@in.ibm.com>
> > > ---
> >
> > Well...
> >
> > 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.

It might be that Lee needs to use -rt CONFIG_PREEMPT_RT to get
the latencies he needs, but given that he is seeing several milliseconds
of delay, I hope we can do better. ;-)

Thanx, Paul
-
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:17    [W:0.072 / U:0.036 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site