On Wed, 10 Jan 2007 13:50:48 +0100 Jarek Poplawski <[EMAIL PROTECTED]> wrote:
> On Wed, Jan 10, 2007 at 10:04:11AM +0100, Jarek Poplawski wrote: > ... > > It looks like you're talking about the right thing > > and I'm a fool again! Now I try to find why I even > > had to pay for this. I read again and again adequate > > chapters from R. Love and C. Benvenuti's books, see > > a lot about kernel preemption in 2.6, but can't see > > anything about preemption disabled in ioctls - maybe > > I'm blind or they are badly translated. Now I look > > into "Linux Device Drivers", see ch. 6 about ioctls, > > blocking I/O and RCU, but nothing about preemption > > disabled again. Maybe this is omited because it's > > obvious to people who started hacking with earlier > > kernels? > > ... or maybe it's even more complicated... > > For the time being, I revoke my critique of these books. > > Jarek P. Don't rely on books too heavily, they can get out of date with a simple code change. The path that I am talking about is the receive skb path. All data received goes through netif_receive_skb and that does rcu_read_lock(). This is done so that receive protocol list can be used with RCU (lock free). Since receiving is a time critical path, we want to process without having to do any locked operations; locked operations cause a processor force a cache miss and are one of the main CPU overheads. RCU requires no locked operation, but does prevent preemption. -- Stephen Hemminger <[EMAIL PROTECTED]> - 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
