On Fri, Jan 27, 2006 at 02:54:12PM -0800, Andrew Morton wrote:
> Eric Dumazet <[email protected]> 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 <[email protected]>
> > > ---
> >
> > 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
