Ravikiran G Thirumalai <[EMAIL PROTECTED]> wrote:
>
> On Thu, Feb 02, 2006 at 07:16:00PM -0800, Andrew Morton wrote:
> > Ravikiran G Thirumalai <[EMAIL PROTECTED]> wrote:
> > >
> > > On Fri, Jan 27, 2006 at 03:01:06PM -0800, Andrew Morton wrote:
> > > Here's an implementation which delegates tuning
On Thu, Feb 02, 2006 at 07:16:00PM -0800, Andrew Morton wrote:
> Ravikiran G Thirumalai <[EMAIL PROTECTED]> wrote:
> >
> > On Fri, Jan 27, 2006 at 03:01:06PM -0800, Andrew Morton wrote:
> > Here's an implementation which delegates tuning of batching to the user. We
> > don't really need local_t at
Ravikiran G Thirumalai <[EMAIL PROTECTED]> wrote:
>
> On Fri, Jan 27, 2006 at 03:01:06PM -0800, Andrew Morton wrote:
> > Ravikiran G Thirumalai <[EMAIL PROTECTED]> wrote:
> >
> >
> > > >
> > > > If the benchmarks say that we need to. If we cannot observe any
> > > > problems
> > > > in testing
On Fri, Jan 27, 2006 at 03:01:06PM -0800, Andrew Morton wrote:
> Ravikiran G Thirumalai <[EMAIL PROTECTED]> wrote:
>
>
> > >
> > > If the benchmarks say that we need to. If we cannot observe any problems
> > > in testing of existing code and if we can't demonstrate any benefit from
> > > the pa
On Sun, Jan 29, 2006 at 07:54:09AM +0100, Eric Dumazet wrote:
> Well, I think that might be doable, maybe RCU magic ?
>
> 1) local_t are not that nice on all archs.
It is for the users that matter, and the hooks are there if someone finds
it to be a performance problem.
> 2) The consolidation p
Benjamin LaHaise a écrit :
On Sat, Jan 28, 2006 at 01:28:20AM +0100, Eric Dumazet wrote:
We might use atomic_long_t only (and no spinlocks)
Something like this ?
Erk, complex and slow... Try using local_t instead, which is substantially
cheaper on the P4 as it doesn't use the lock prefix and
[adding linux-arch]
On Sunday 29 January 2006 01:55, Andrew Morton wrote:
> Benjamin LaHaise <[EMAIL PROTECTED]> wrote:
> > On Sat, Jan 28, 2006 at 01:28:20AM +0100, Eric Dumazet wrote:
> > > We might use atomic_long_t only (and no spinlocks)
> > > Something like this ?
> >
> > Erk, complex and sl
On Sat, Jan 28, 2006 at 08:19:44PM -0500, Benjamin LaHaise wrote:
> The overuse of atomics is horrific in what is being proposed. All the
> major architectures except powerpc (i386, x86-64, ia64, and sparc64)
> implement local_t. It would make far more sense to push the last few
> stragglers (w
Benjamin LaHaise <[EMAIL PROTECTED]> wrote:
>
> On Sat, Jan 28, 2006 at 04:55:49PM -0800, Andrew Morton wrote:
> > local_t isn't much use until we get rid of asm-generic/local.h. Bloaty,
> > racy with nested interrupts.
>
> The overuse of atomics is horrific in what is being proposed.
Well yeah,
On Sat, Jan 28, 2006 at 04:55:49PM -0800, Andrew Morton wrote:
> local_t isn't much use until we get rid of asm-generic/local.h. Bloaty,
> racy with nested interrupts.
The overuse of atomics is horrific in what is being proposed. All the
major architectures except powerpc (i386, x86-64, ia64, an
Benjamin LaHaise <[EMAIL PROTECTED]> wrote:
>
> On Sat, Jan 28, 2006 at 01:28:20AM +0100, Eric Dumazet wrote:
> > We might use atomic_long_t only (and no spinlocks)
> > Something like this ?
>
> Erk, complex and slow... Try using local_t instead, which is substantially
> cheaper on the P4 as it
On Sat, Jan 28, 2006 at 01:28:20AM +0100, Eric Dumazet wrote:
> We might use atomic_long_t only (and no spinlocks)
> Something like this ?
Erk, complex and slow... Try using local_t instead, which is substantially
cheaper on the P4 as it doesn't use the lock prefix and act as a memory
barrier.
Ravikiran G Thirumalai a écrit :
On Sat, Jan 28, 2006 at 01:35:03AM +0100, Eric Dumazet wrote:
Eric Dumazet a écrit :
Andrew Morton a écrit :
Eric Dumazet <[EMAIL PROTECTED]> wrote:
long percpu_counter_read_accurate(struct percpu_counter *fbc)
{
long res = 0;
int cpu;
On Sat, Jan 28, 2006 at 01:35:03AM +0100, Eric Dumazet wrote:
> Eric Dumazet a écrit :
> >Andrew Morton a écrit :
> >>Eric Dumazet <[EMAIL PROTECTED]> wrote:
> >
> >#ifdef CONFIG_SMP
> >void percpu_counter_mod(struct percpu_counter *fbc, long amount)
> >{
> > long old, new;
> > atomic_long_
Eric Dumazet <[EMAIL PROTECTED]> wrote:
>
> [PATCH] Add atomic_long_xchg() and atomic_long_cmpxchg() wrappers
>
> ...
>
> +static inline long atomic_long_xchg(atomic_long_t *l, long val)
> +{
> + atomic64_t *v = (atomic64_t *)l;
> + return atomic64_xchg(v, val);
All we need now is some
Andrew Morton a écrit :
Eric Dumazet <[EMAIL PROTECTED]> wrote:
An advantage of retaining a spinlock in percpu_counter is that if accuracy
is needed at a low rate (say, /proc reading) we can take the lock and then
go spill each CPU's local count into the main one. It would need to be a
very low
Eric Dumazet <[EMAIL PROTECTED]> wrote:
>
> >
> > An advantage of retaining a spinlock in percpu_counter is that if accuracy
> > is needed at a low rate (say, /proc reading) we can take the lock and then
> > go spill each CPU's local count into the main one. It would need to be a
> > very low rat
On Sat, Jan 28, 2006 at 12:21:07AM +0100, Eric Dumazet wrote:
> Ravikiran G Thirumalai a écrit :
> >On Fri, Jan 27, 2006 at 11:30:23PM +0100, Eric Dumazet wrote:
>
> Why not use a boot time allocated percpu area (as done today in
> setup_per_cpu_areas()), but instead of reserving extra space for
Eric Dumazet a écrit :
Andrew Morton a écrit :
Eric Dumazet <[EMAIL PROTECTED]> wrote:
Ravikiran G Thirumalai a écrit :
On Fri, Jan 27, 2006 at 12:16:02PM -0800, Andrew Morton wrote:
Ravikiran G Thirumalai <[EMAIL PROTECTED]> wrote:
which can be assumed as not frequent. At
sk_stream_mem_sch
Ravikiran G Thirumalai <[EMAIL PROTECTED]> wrote:
>
> On Fri, Jan 27, 2006 at 03:08:47PM -0800, Andrew Morton wrote:
> > Andrew Morton <[EMAIL PROTECTED]> wrote:
> > >
> > > Oh, and because vm_acct_memory() is counting a singleton object, it can
> > > use
> > > DEFINE_PER_CPU rather than alloc_per
Andrew Morton a écrit :
Eric Dumazet <[EMAIL PROTECTED]> wrote:
Ravikiran G Thirumalai a écrit :
On Fri, Jan 27, 2006 at 12:16:02PM -0800, Andrew Morton wrote:
Ravikiran G Thirumalai <[EMAIL PROTECTED]> wrote:
which can be assumed as not frequent.
At sk_stream_mem_schedule(), read_sockets_al
On Fri, Jan 27, 2006 at 03:08:47PM -0800, Andrew Morton wrote:
> Andrew Morton <[EMAIL PROTECTED]> wrote:
> >
> > Oh, and because vm_acct_memory() is counting a singleton object, it can use
> > DEFINE_PER_CPU rather than alloc_percpu(), so it saves on a bit of kmalloc
> > overhead.
>
> Actually, I
Ravikiran G Thirumalai a écrit :
On Fri, Jan 27, 2006 at 11:30:23PM +0100, Eric Dumazet wrote:
There are several issues here :
alloc_percpu() current implementation is a a waste of ram. (because it uses
slab allocations that have a minimum size of 32 bytes)
Oh there was a solution for that :
Eric Dumazet <[EMAIL PROTECTED]> wrote:
>
> Ravikiran G Thirumalai a écrit :
> > On Fri, Jan 27, 2006 at 12:16:02PM -0800, Andrew Morton wrote:
> >> Ravikiran G Thirumalai <[EMAIL PROTECTED]> wrote:
> >>> which can be assumed as not frequent.
> >>> At sk_stream_mem_schedule(), read_sockets_alloca
Ravikiran G Thirumalai <[EMAIL PROTECTED]> wrote:
>
> On Fri, Jan 27, 2006 at 12:16:02PM -0800, Andrew Morton wrote:
> > Ravikiran G Thirumalai <[EMAIL PROTECTED]> wrote:
> > >
> > > which can be assumed as not frequent.
> > > At sk_stream_mem_schedule(), read_sockets_allocated() is invoked only
Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> Oh, and because vm_acct_memory() is counting a singleton object, it can use
> DEFINE_PER_CPU rather than alloc_percpu(), so it saves on a bit of kmalloc
> overhead.
Actually, I don't think that's true. we're allocating a sizeof(long) with
kmalloc_node(
Ravikiran G Thirumalai a écrit :
On Fri, Jan 27, 2006 at 12:16:02PM -0800, Andrew Morton wrote:
Ravikiran G Thirumalai <[EMAIL PROTECTED]> wrote:
which can be assumed as not frequent.
At sk_stream_mem_schedule(), read_sockets_allocated() is invoked only
certain conditions, under memory pressu
On Fri, Jan 27, 2006 at 11:30:23PM +0100, Eric Dumazet wrote:
>
> There are several issues here :
>
> alloc_percpu() current implementation is a a waste of ram. (because it uses
> slab allocations that have a minimum size of 32 bytes)
Oh there was a solution for that :).
http://lwn.net/Artic
On Fri, Jan 27, 2006 at 12:16:02PM -0800, Andrew Morton wrote:
> Ravikiran G Thirumalai <[EMAIL PROTECTED]> wrote:
> >
> > which can be assumed as not frequent.
> > At sk_stream_mem_schedule(), read_sockets_allocated() is invoked only
> > certain conditions, under memory pressure -- on a large C
Andrew Morton a écrit :
Ravikiran G Thirumalai <[EMAIL PROTECTED]> wrote:
On Fri, Jan 27, 2006 at 09:53:53AM +0100, Eric Dumazet wrote:
Ravikiran G Thirumalai a écrit :
Change the atomic_t sockets_allocated member of struct proto to a
per-cpu counter.
Signed-off-by: Pravin B. Shelar <[EMAIL
Ravikiran G Thirumalai <[EMAIL PROTECTED]> wrote:
>
> On Fri, Jan 27, 2006 at 09:53:53AM +0100, Eric Dumazet wrote:
> > Ravikiran G Thirumalai a écrit :
> > >Change the atomic_t sockets_allocated member of struct proto to a
> > >per-cpu counter.
> > >
> > >Signed-off-by: Pravin B. Shelar <[EMAIL P
On Fri, Jan 27, 2006 at 09:53:53AM +0100, Eric Dumazet wrote:
> Ravikiran G Thirumalai a écrit :
> >Change the atomic_t sockets_allocated member of struct proto to a
> >per-cpu counter.
> >
> >Signed-off-by: Pravin B. Shelar <[EMAIL PROTECTED]>
> >Signed-off-by: Ravikiran Thirumalai <[EMAIL PROTEC
Ravikiran G Thirumalai a écrit :
Change the atomic_t sockets_allocated member of struct proto to a
per-cpu counter.
Signed-off-by: Pravin B. Shelar <[EMAIL PROTECTED]>
Signed-off-by: Ravikiran Thirumalai <[EMAIL PROTECTED]>
Signed-off-by: Shai Fultheim <[EMAIL PROTECTED]>
Hi Ravikiran
If I c
Change the atomic_t sockets_allocated member of struct proto to a
per-cpu counter.
Signed-off-by: Pravin B. Shelar <[EMAIL PROTECTED]>
Signed-off-by: Ravikiran Thirumalai <[EMAIL PROTECTED]>
Signed-off-by: Shai Fultheim <[EMAIL PROTECTED]>
Index: linux-2.6.16-rc1/include/net/sock.h
=
34 matches
Mail list logo
