On Tue, 2006-08-08 at 22:44 -0700, Daniel Phillips wrote:

David Miller wrote:

quoted

From: Daniel Phillips <redacted>

quoted

David Miller wrote:

quoted

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.

quoted

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.