On Thu, Mar 09, 2006 at 07:41:08PM +1100, Nick Piggin wrote:
> Considering that local_t has been broken so that basically nobody
> is using it, now is a great time to rethink the types before it
> gets fixed and people start using it.
I'm starting to get more concerned as the per-cpu changes that
On Thursday 09 March 2006 09:06, Ravikiran G Thirumalai wrote:
> On Wed, Mar 08, 2006 at 04:32:58PM -0800, Andrew Morton wrote:
> > Ravikiran G Thirumalai <[EMAIL PROTECTED]> wrote:
> > >
> > > On Wed, Mar 08, 2006 at 03:43:21PM -0800, Andrew Morton wrote:
> > > > Benjamin LaHaise <[EMAIL PROTECTED
Ravikiran G Thirumalai wrote:
On Thu, Mar 09, 2006 at 07:14:26PM +1100, Nick Piggin wrote:
Ravikiran G Thirumalai wrote:
Here's a patch making x86_64 local_t to 64 bits like other 64 bit arches.
This keeps local_t unsigned long. (We can change it to signed value
along with other arches lat
On Thu, Mar 09, 2006 at 07:14:26PM +1100, Nick Piggin wrote:
> Ravikiran G Thirumalai wrote:
>
> >Here's a patch making x86_64 local_t to 64 bits like other 64 bit arches.
> >This keeps local_t unsigned long. (We can change it to signed value
> >along with other arches later in one go I guess)
Ravikiran G Thirumalai wrote:
Here's a patch making x86_64 local_t to 64 bits like other 64 bit arches.
This keeps local_t unsigned long. (We can change it to signed value
along with other arches later in one go I guess)
Why not just keep naming and structure of interfaces consistent with
On Wed, Mar 08, 2006 at 04:32:58PM -0800, Andrew Morton wrote:
> Ravikiran G Thirumalai <[EMAIL PROTECTED]> wrote:
> >
> > On Wed, Mar 08, 2006 at 03:43:21PM -0800, Andrew Morton wrote:
> > > Benjamin LaHaise <[EMAIL PROTECTED]> wrote:
> > > >
> > > > I think it may make more sense to simply conver
Andi Kleen <[EMAIL PROTECTED]> wrote:
>
> Andrew Morton <[EMAIL PROTECTED]> writes:
> >
> > x86_64 is signed 32-bit!
>
> I'll change it. You want signed 64bit?
>
Well it's all random at present. Since the API is defined as unsigned I
guess it's be best to make it unsigned for now. Later, when
Andrew Morton <[EMAIL PROTECTED]> writes:
>
> x86_64 is signed 32-bit!
I'll change it. You want signed 64bit?
-Andi
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Ravikiran G Thirumalai <[EMAIL PROTECTED]> wrote:
>
> On Wed, Mar 08, 2006 at 03:43:21PM -0800, Andrew Morton wrote:
> > Benjamin LaHaise <[EMAIL PROTECTED]> wrote:
> > >
> > > I think it may make more sense to simply convert local_t into a long,
> > > given
> > > that most of the users will be t
On Wed, Mar 08, 2006 at 03:43:21PM -0800, Andrew Morton wrote:
> Benjamin LaHaise <[EMAIL PROTECTED]> wrote:
> >
> > I think it may make more sense to simply convert local_t into a long, given
> > that most of the users will be things like stats counters.
> >
>
> Yes, I agree that making local_t
Benjamin LaHaise <[EMAIL PROTECTED]> wrote:
>
> On Wed, Mar 08, 2006 at 02:25:28PM -0800, Ravikiran G Thirumalai wrote:
> > Then, for the batched percpu_counters, we could gain by using local_t only
> > for
> > the UP case. But we will have to have a new local_long_t implementation
> > for that.
Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> Once decrapify-asm-generic-localh.patch is merged I think all architectures
> can and should use asm-generic/local.h.
err, no. Because that's just atomic_long_t, and that's a locked instruction.
We need to review and fix up those architectures which
Ravikiran G Thirumalai <[EMAIL PROTECTED]> wrote:
>
> On Wed, Mar 08, 2006 at 04:17:33PM -0500, Benjamin LaHaise wrote:
> > On Wed, Mar 08, 2006 at 01:07:26PM -0800, Ravikiran G Thirumalai wrote:
> >
> > Last time I checked, all the major architectures had efficient local_t
> > implementations.
On Wed, Mar 08, 2006 at 02:25:28PM -0800, Ravikiran G Thirumalai wrote:
> Then, for the batched percpu_counters, we could gain by using local_t only
> for
> the UP case. But we will have to have a new local_long_t implementation
> for that. Do you think just one use case of local_long_t warrant
On Wed, Mar 08, 2006 at 04:17:33PM -0500, Benjamin LaHaise wrote:
> On Wed, Mar 08, 2006 at 01:07:26PM -0800, Ravikiran G Thirumalai wrote:
>
> Last time I checked, all the major architectures had efficient local_t
> implementations. Most of the RISC CPUs are able to do a load / store
> conditi
On Wed, Mar 08, 2006 at 01:07:26PM -0800, Ravikiran G Thirumalai wrote:
> But on non x86, local_bh_disable() is gonna be cheaper than a cli/atomic op
> no?
> (Even if they were switched over to do local_irq_save() and
> local_irq_restore() from atomic_t's that is).
It's still more expensive than
On Wed, Mar 08, 2006 at 03:36:42PM -0500, Benjamin LaHaise wrote:
> On Wed, Mar 08, 2006 at 12:26:56PM -0800, Ravikiran G Thirumalai wrote:
> > +static inline void percpu_counter_mod_bh(struct percpu_counter *fbc, long
> > amount)
> > +{
> > + local_bh_disable();
> > + fbc->count += amount;
>
On Wed, Mar 08, 2006 at 12:26:56PM -0800, Ravikiran G Thirumalai wrote:
> +static inline void percpu_counter_mod_bh(struct percpu_counter *fbc, long
> amount)
> +{
> + local_bh_disable();
> + fbc->count += amount;
> + local_bh_enable();
> +}
Please use local_t instead, then you don't
On Tue, Mar 07, 2006 at 06:13:01PM -0800, Andrew Morton wrote:
> Ravikiran G Thirumalai <[EMAIL PROTECTED]> wrote:
> >
> > +static inline void percpu_counter_mod_bh(struct percpu_counter *fbc, long
> > amount)
> > +{
> > + local_bh_disable();
> > + percpu_counter_mod(fbc, amount);
> > + loc
Ravikiran G Thirumalai <[EMAIL PROTECTED]> wrote:
>
> +static inline void percpu_counter_mod_bh(struct percpu_counter *fbc, long
> amount)
> +{
> +local_bh_disable();
> +percpu_counter_mod(fbc, amount);
> +local_bh_enable();
> +}
> +
percpu_counter_mod() does preempt_disable(),
Add percpu_counter_mod_bh for using these counters safely from
both softirq and process context.
Signed-off by: Pravin B. Shelar <[EMAIL PROTECTED]>
Signed-off by: Ravikiran G Thirumalai <[EMAIL PROTECTED]>
Signed-off by: Shai Fultheim <[EMAIL PROTECTED]>
Index: linux-2.6.16-rc5mm3/include/linux/
21 matches
Mail list logo
