Eric Dumazet wrote:
Furthermore, a lazy sync would mean to change sysctl proc_handler for
"file-nr" to perform a synchronize before calling proc_dointvec, this
would be really obscure.
I was only using your terminology (ie. the 'lazy' synch after the
atomic is updated).
Actually, a better
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
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
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() being 'an atomic op'
(untrue), so my second
On Fri, Aug 26, 2005 at 12:51:30AM +1000, Nick Piggin wrote:
> Eric Dumazet wrote:
> >Nick Piggin a ?crit :
> >
>
> >>Would you just be able to add the atomic sysctl handler that
> >>Christoph suggested?
> >>
> >
> >Quite a lot of work indeed, and it would force to convert 3 int
> >(nr_files,
Eric Dumazet wrote:
Nick Piggin a écrit :
Would you just be able to add the atomic sysctl handler that
Christoph suggested?
Quite a lot of work indeed, and it would force to convert 3 int
(nr_files, nr_free_files, max_files) to 3 atomic_t. I feel bad
introducing a lot of sysctl rework
Nick Piggin a écrit :
On Thu, 2005-08-25 at 12:41 +0200, Eric Dumazet wrote:
OK, here is a new clean patch that address this problem (nothing assumed about
atomics)
Would you just be able to add the atomic sysctl handler that
Christoph suggested?
Quite a lot of work indeed, and it
On Thu, 2005-08-25 at 12:41 +0200, Eric Dumazet wrote:
> OK, here is a new clean patch that address this problem (nothing assumed
> about
> atomics)
>
Would you just be able to add the atomic sysctl handler that
Christoph suggested?
This introduces lost update problems. 2 CPUs may store to
Christoph Hellwig a écrit :
On Thu, Aug 25, 2005 at 11:17:23AM +0200, Eric Dumazet wrote:
But that's not true. You need to write you own sysctl handler for it,
probably worth adding a generic atomic_t sysctl handler while you're
at it.
I checked linux-2.6.13-rc7 tree, and atomic_read() is
> >
> > this patch adds atomic ops where there were none before
>
> nope... a spinlock/spinunlock contains atomic ops.
unlock usually doesn't but ok
>
> > for those architectures that need atomics for read (parisc? arm?)
>
> not today. No atomic needed for read.
>
> >
> > however..
On Thu, Aug 25, 2005 at 11:17:23AM +0200, Eric Dumazet wrote:
> >But that's not true. You need to write you own sysctl handler for it,
> >probably worth adding a generic atomic_t sysctl handler while you're
> >at it.
> >
>
> I checked linux-2.6.13-rc7 tree, and atomic_read() is just a wrapper to
Arjan van de Ven a écrit :
On Thu, 2005-08-25 at 10:45 +0200, Eric Dumazet wrote:
This patch removes filp_count_lock spinlock, used to protect
files_stat.nr_files.
Just use atomic_t type and atomic_inc()/atomic_dec() operations.
This patch assumes that atomic_read() is a plain {return
Christoph Hellwig a écrit :
On Thu, Aug 25, 2005 at 10:45:12AM +0200, Eric Dumazet wrote:
This patch assumes that atomic_read() is a plain {return v->counter;} on
all architectures. (keywords : sysctl, /proc/sys/fs/file-nr, proc_dointvec)
But that's not true. You need to write you own
On Thu, 2005-08-25 at 10:45 +0200, Eric Dumazet wrote:
> This patch removes filp_count_lock spinlock, used to protect
> files_stat.nr_files.
>
> Just use atomic_t type and atomic_inc()/atomic_dec() operations.
>
> This patch assumes that atomic_read() is a plain {return v->counter;} on all
>
On Thu, Aug 25, 2005 at 10:45:12AM +0200, Eric Dumazet wrote:
> This patch assumes that atomic_read() is a plain {return v->counter;} on
> all architectures. (keywords : sysctl, /proc/sys/fs/file-nr, proc_dointvec)
But that's not true. You need to write you own sysctl handler for it,
probably
This patch removes filp_count_lock spinlock, used to protect
files_stat.nr_files.
Just use atomic_t type and atomic_inc()/atomic_dec() operations.
This patch assumes that atomic_read() is a plain {return v->counter;} on all
architectures. (keywords : sysctl, /proc/sys/fs/file-nr,
This patch removes filp_count_lock spinlock, used to protect
files_stat.nr_files.
Just use atomic_t type and atomic_inc()/atomic_dec() operations.
This patch assumes that atomic_read() is a plain {return v-counter;} on all
architectures. (keywords : sysctl, /proc/sys/fs/file-nr,
On Thu, Aug 25, 2005 at 10:45:12AM +0200, Eric Dumazet wrote:
This patch assumes that atomic_read() is a plain {return v-counter;} on
all architectures. (keywords : sysctl, /proc/sys/fs/file-nr, proc_dointvec)
But that's not true. You need to write you own sysctl handler for it,
probably
On Thu, 2005-08-25 at 10:45 +0200, Eric Dumazet wrote:
This patch removes filp_count_lock spinlock, used to protect
files_stat.nr_files.
Just use atomic_t type and atomic_inc()/atomic_dec() operations.
This patch assumes that atomic_read() is a plain {return v-counter;} on all
Christoph Hellwig a écrit :
On Thu, Aug 25, 2005 at 10:45:12AM +0200, Eric Dumazet wrote:
This patch assumes that atomic_read() is a plain {return v-counter;} on
all architectures. (keywords : sysctl, /proc/sys/fs/file-nr, proc_dointvec)
But that's not true. You need to write you own
Arjan van de Ven a écrit :
On Thu, 2005-08-25 at 10:45 +0200, Eric Dumazet wrote:
This patch removes filp_count_lock spinlock, used to protect
files_stat.nr_files.
Just use atomic_t type and atomic_inc()/atomic_dec() operations.
This patch assumes that atomic_read() is a plain {return
On Thu, Aug 25, 2005 at 11:17:23AM +0200, Eric Dumazet wrote:
But that's not true. You need to write you own sysctl handler for it,
probably worth adding a generic atomic_t sysctl handler while you're
at it.
I checked linux-2.6.13-rc7 tree, and atomic_read() is just a wrapper to
read
this patch adds atomic ops where there were none before
nope... a spinlock/spinunlock contains atomic ops.
unlock usually doesn't but ok
for those architectures that need atomics for read (parisc? arm?)
not today. No atomic needed for read.
however.. wouldn't it be better
Christoph Hellwig a écrit :
On Thu, Aug 25, 2005 at 11:17:23AM +0200, Eric Dumazet wrote:
But that's not true. You need to write you own sysctl handler for it,
probably worth adding a generic atomic_t sysctl handler while you're
at it.
I checked linux-2.6.13-rc7 tree, and atomic_read() is
On Thu, 2005-08-25 at 12:41 +0200, Eric Dumazet wrote:
OK, here is a new clean patch that address this problem (nothing assumed
about
atomics)
Would you just be able to add the atomic sysctl handler that
Christoph suggested?
This introduces lost update problems. 2 CPUs may store to
Nick Piggin a écrit :
On Thu, 2005-08-25 at 12:41 +0200, Eric Dumazet wrote:
OK, here is a new clean patch that address this problem (nothing assumed about
atomics)
Would you just be able to add the atomic sysctl handler that
Christoph suggested?
Quite a lot of work indeed, and it
Eric Dumazet wrote:
Nick Piggin a écrit :
Would you just be able to add the atomic sysctl handler that
Christoph suggested?
Quite a lot of work indeed, and it would force to convert 3 int
(nr_files, nr_free_files, max_files) to 3 atomic_t. I feel bad
introducing a lot of sysctl rework
On Fri, Aug 26, 2005 at 12:51:30AM +1000, Nick Piggin wrote:
Eric Dumazet wrote:
Nick Piggin a ?crit :
Would you just be able to add the atomic sysctl handler that
Christoph suggested?
Quite a lot of work indeed, and it would force to convert 3 int
(nr_files, nr_free_files,
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
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
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
Eric Dumazet wrote:
Furthermore, a lazy sync would mean to change sysctl proc_handler for
file-nr to perform a synchronize before calling proc_dointvec, this
would be really obscure.
I was only using your terminology (ie. the 'lazy' synch after the
atomic is updated).
Actually, a better
32 matches
Mail list logo
