[lkml]   [2005]   [Aug]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] removes filp_count_lock and changes nr_files type to atomic_t
On Thu, Aug 25, 2005 at 11:49:35PM +0530, Dipankar Sarma wrote:
> On Thu, Aug 25, 2005 at 05:13:05PM +0200, Eric Dumazet wrote:
> > Nick Piggin a ?crit :
> >
> > >OK, well I would prefer you do the proper atomic operations throughout
> > >where it "really matters" in file_table.c, and do your lazy synchronize
> > >with just the sysctl exported value.
> > >
> >
> > But... I got complains about atomic_read(&counter) being 'an atomic op'
> > (untrue), so my second patch just doesnt touch the path where nr_files was
> > read.
> >
> Here is a patch that I had done some time ago that uses atomic_t,
> yet retains the sysctl handler. Eric, you earlier patch is incorrect
> exactly for that reason.
> One other thing - the claim that it removes filp_count_lock
> from fast path is bogus. The slab constructor/destructors are
> called only when we return the free file structs to the page
> allocator. That we don't do very often and therefore we
> don't acquire the lock - atleast not for every filp open
> and close.
> This is not to say we don't want a better reference counter like
> a per-cpu counter, but there is some difficult stuff there and
> the returns need to justify that. I would appreciate if you
> or anyone can demonstrate this to be a problem.
> The patch below was meant for debugging some suspected problems
> with -mm.

As mentioned when we last discussed it the nr_files usage in XFS
is boguss and should go away first so we don't need the accessor
and export. Hopefully we can get rid of the max_files usage
in af_unix aswell, can you ping davem on it?

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: 2005-08-25 20:40    [W:0.058 / U:0.036 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site