[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <1400175212.7973.145.camel@edumazet-glaptop2.roam.corp.google.com>
Date: Thu, 15 May 2014 10:33:32 -0700
From: Eric Dumazet <eric.dumazet@...il.com>
To: Zoltan Kiss <zoltan.kiss@...rix.com>
Cc: netdev@...r.kernel.org, David Miller <davem@...emloft.net>,
David Vrabel <david.vrabel@...rix.com>,
xen-devel@...ts.xenproject.org,
Ian Campbell <ian.campbell@...rix.com>,
Wei Liu <wei.liu2@...rix.com>
Subject: Re: interrupt moving and NAPI scheduling
On Thu, 2014-05-15 at 17:26 +0100, Zoltan Kiss wrote:
> Hi,
>
> Let me bump this question: how does the kernel make sure that if an
> interrupt is moved away from CPU X to Y (e.g. by irqbalance), the NAPI
> instance already scheduled on CPU Y won't race with the interrupt? I
> mean the following scenario:
>
> 1. instance calls napi_complete on CPU X
> 2. that removes the instance from the list
> 3. interrupt happens on CPU Y
> 4. "!test_and_set_bit(NAPI_STATE_SCHED, &n->state)" fails, as the bit is
> still set
> 5. instance not added to the list therefore
> 6. napi_complete on CPU X clear the bit
>
> My assumption is that when the interrupt moved, the kernel makes sure
> the NAPI instance won't get scheduled on the old CPU, but I'm not sure
> about it
Interrupts are supposed to be disabled at the time we call
napi_complete().
Some drivers are buggy.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists