[ovs-dev] [PATCH 2/2] datapath: Add loop detection for RT kernels.

Jesse Gross jesse at nicira.com
Mon Oct 25 20:06:34 UTC 2010


On Mon, Oct 25, 2010 at 10:01 AM, Ben Pfaff <blp at nicira.com> wrote:
> On Fri, Oct 22, 2010 at 04:34:14PM -0700, Jesse Gross wrote:
>> Our normal loop detection is fairly lightweight but requires
>> disabling preemption while packet processing takes place.  On
>> RT kernels this isn't acceptable and interacts badly with spinlocks,
>> so we can't use it.  This implements a form of pseudo thread local
>> storage and uses that instead as it is capable of tracking a thread
>> across CPU migrations.  It is more expensive than the preemption
>> disabled version, so we continue to use that on non-RT kernels.
>>
>> Signed-off-by: Jesse Gross <jesse at nicira.com>
>
> I assume that we would revert this before submitting upstream?

Yes, this falls in the category of compatibility code that we'll have to remove.

>
> Is realtime with NR_CPUS==1 an interesting special case?  We could just
> use the non-RT implementation in that case, I think.

I don't think we can take a shortcut here.  Even on a uniprocessor
system preemption is still allowed so we have the same considerations
as SMP.  We can't disable preemption (as the non-RT version does)
since that's what causes the problems in the first place.

>
> Softirqs are always threaded on RT, right?  So that means that we'd
> always have a task_struct.  RT adds an "extra_flags" member to
> task_struct but only uses two bits of it.  We could abuse other bits as
> a counter.

Hmm, that's a good point.  We can definitely shrink down our counter
struct so that it will fit and it seems unlikely that either our
struct or the number of flags will need to expand significantly in the
future.  It's a little bit risky but it's a lot simpler.  I guess I'll
send out another patch implementing it that way instead.




More information about the dev mailing list