--
When I'm asked what language is my mother tongue,
I simply answer "C".
On Tue, 28 Aug 2007, David Miller wrote:
> From: Masayuki Nakagawa <nakagawa.msy@xxxxxxxxxxxxxx>
> Date: Tue, 28 Aug 2007 18:41:38 -0700
>
> > +static inline void __inet_hash_setbit(unsigned long *bitmask,
> > + unsigned int index)
> > +{
> > + if (bitmask)
> > + set_bit(index, bitmask);
> > +}
> > +
> > +static inline void __inet_hash_clearbit(unsigned long *bitmask,
> > + unsigned int index)
> > +{
> > + if (bitmask)
> > + clear_bit(index, bitmask);
> > +}
> > +
>
> A new atomic operation every single socket hashing insert or delete
> operation is way too much amount of overhead for what should be a
> trivial problem.
Indeed it is.
>
> Please fix this in another way that does not add new locks or atomics
> to the socket creation and destruction fast paths, thank you.
>
This was originally written back when there was a bh lock around the
entire loop (IIRC). It caused quite a bit of latency problems back then.
I'll have to take a look to see if it is even still a problem.
If it is, then we'll need to find another fix for it. Unfortunately, it's
not that trivial (if it is still a problem). Since we need a way to look a
a large number of buckets without looping through checking each one.
Lee, I think you were the one to notice this source of latency back when
it was first discovered. If I write a patch to back this out of the -rt
kernel, could you see if it is still an issue?
Thanks,
-- Steve
-
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
