On Tue, 2006-08-08 at 22:44 -0700, Daniel Phillips wrote: > David Miller wrote: > >From: Daniel Phillips <[EMAIL PROTECTED]> > >>David Miller wrote: > >>>I think the new atomic operation that will seemingly occur on every > >>>device SKB free is unacceptable. > >> > >>Alternate suggestion? > > > > Sorry, I have none. But you're unlikely to get your changes > > considered seriously unless you can avoid any new overhead your patch > > has which is of this level. > > We just skip anything new unless the socket is actively carrying block > IO traffic, in which case we pay a miniscule price to avoid severe > performance artifacts or in the worst case, deadlock. So in this design > the new atomic operation does not occur on every device SKP free. > > All atomic ops sit behind the cheap test: > > (dev->flags & IFF_MEMALLOC) > > or if any have escaped that is just an oversight. Peter?
That should be so indeed. Except on the allocation path ofcourse, there it only occurs when the first allocation fails. > > We're busy trying to make these data structures smaller, and eliminate > > atomic operations, as much as possible. Therefore anything which adds > > new datastructure elements and new atomic operations will be met with > > fierce resistence unless it results an equal or greater shrink of > > datastructures elsewhere or removes atomic operations elsewhere in > > the critical path. > > Right now we have a problem because our network stack cannot support > block IO reliably. Without that, Linux is no enterprise storage > platform. Indeed, surely not all wanted new features come with zero cost. If its a hard condition that all new features remove data and operations progress is going to be challenging. - 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
