Prev: [PATCH] block: remove 16 bytes of padding from struct request on 64bits
Next: ivtv: sizeof() => ARRAY_SIZE()
From: Nick Piggin on 6 Apr 2010 01:10
On Thu, Apr 01, 2010 at 08:55:59AM -0700, Linus Torvalds wrote:
>
>
> On Thu, 1 Apr 2010, Nick Piggin wrote:
> >
> > I think it can be done racelessly with my patch, which is not really too
> > much overhead. I think if this is considered too much, then we should
> > either fix code and preferably de-export and remove module_refcount from
> > drivers, or remove module removal completely.
>
> I doubt your patch matters too much, but I like it conceptually and it
> seems to be a nice basis for perhaps doing something clever in the long
> run.
>
> [ ie avoiding the stop_machine and instead perhaps doing some optimistic
> thing like "see if we seem to be unused right now, then unregister us,
> and see - after unregistering - that the usage counts haven't increased,
> and re-register if they have. ]

That's true, reducing the requirement for stop_machine is always a nice
thing to have.

Also if anyone else is looking at a way to do _really_ scalable
refcounting elsewhere, this could be a good template (I certainly looked
here first when trying to get ideas for vfsmount refcounting).


> So I'd like to apply it as a "good improvement, even if module unloading
> which is the only thing that _should_ care deeply should already be under
> stop-machine".
>
> But I'd like an ack or two first.

Sure, I'll let Rusty push it to you when he's happy with it.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Eric Dumazet on 6 Apr 2010 02:20
Le mardi 06 avril 2010 à 15:05 +1000, Nick Piggin a écrit :

> Also if anyone else is looking at a way to do _really_ scalable
> refcounting elsewhere, this could be a good template (I certainly looked
> here first when trying to get ideas for vfsmount refcounting).

Yes, nice trick Nick, I was thinking about it for network code :)

Acked-by: Eric Dumazet <eric.dumazet(a)gmail.com>

I confess the smp_wmb() in module_put() bothered me a bit until I saw it
was only a barrier() on X86 (if !CONFIG_X86_OOSTORE)



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Nick Piggin on 6 Apr 2010 03:40
On Tue, Apr 06, 2010 at 08:19:23AM +0200, Eric Dumazet wrote:
> Le mardi 06 avril 2010 � 15:05 +1000, Nick Piggin a �crit :
>
> > Also if anyone else is looking at a way to do _really_ scalable
> > refcounting elsewhere, this could be a good template (I certainly looked
> > here first when trying to get ideas for vfsmount refcounting).
>
> Yes, nice trick Nick, I was thinking about it for network code :)
>
> Acked-by: Eric Dumazet <eric.dumazet(a)gmail.com>
>
> I confess the smp_wmb() in module_put() bothered me a bit until I saw it
> was only a barrier() on X86 (if !CONFIG_X86_OOSTORE)

Yep. smp_wmb() and smp_rmb() are both noops on x86 (OOSTORE is some
really obscure thing that we don't need to worry about really). On
POWER6/7 CPUs, it uses lwsync which is fairly cheap as well.

I think refcounting in _general_ needs a smp_wmb() (or, to be more
precise, probably a release barrier) before decrements because you don't
want previous futzing with the object to leak into after a final
decrement may be observed by another CPU. So it might be hard to avoid
anyway.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
First  |  Prev  | 
Pages: 1 2
Prev: [PATCH] block: remove 16 bytes of padding from struct request on 64bits
Next: ivtv: sizeof() => ARRAY_SIZE()