Re: [RFC][PATCH 0/9] Network receive deadlock prevention for NBD

On Wed, 2006-08-09 at 09:46 +0400, Evgeniy Polyakov wrote:
On Tue, Aug 08, 2006 at 09:33:25PM +0200, Peter Zijlstra (a.p.zijlstra@xxxxxxxxx) wrote:
http://lwn.net/Articles/144273/
"Kernel Summit 2005: Convergence of network and storage paths"

We believe that an approach very much like today's patch set is
necessary for NBD, iSCSI, AoE or the like ever to work reliably.
We further believe that a properly working version of at least one of
these subsystems is critical to the viability of Linux as a modern
storage platform.

There is another approach for that - do not use slab allocator for
network dataflow at all. It automatically has all you pros amd if
implemented correctly can have a lot of additional usefull and
high-performance features like full zero-copy and total fragmentation
avoidance.

On your site where you explain the Network Tree Allocator:

http://tservice.net.ru/~s0mbre/blog/devel/networking/nta/index.html

You only test the fragmentation scenario with the full scale of sizes.
Fragmentation will look different if you use a limited number of sizes
that share no factors (other than the block size); try 19, 37 and 79
blocks with 1:1:1 ratio.

Also, I have yet to see how you will do full zero-copy receives; full
zero-copy would mean getting the data from driver DMA to user-space
without
a single copy. The to user-space part almost requires that each packet
live
on its own page.

As for the VM deadlock avoidance; I see no zero overhead allocation path
-
you do not want to deadlock your allocator. I see no critical resource
isolation (our SOCK_MEMALLOC). Without these things your allocator might
improve the status quo but it will not aid in avoiding the deadlock we
try
to tackle here.



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: [RFC][PATCH 0/9] Network receive deadlock prevention for NBD
    ... Convergence of network and storage paths" ... On your site where you explain the Network Tree Allocator: ... power-of-two (I use 32 bytes alignemnt, as the smallest one which SLAB ... The to user-space part almost requires that each packet ...
    (Linux-Kernel)
  • Re: [PATCH 1/1] network memory allocator.
    ... I'm not understanding, if you have a page A with two packets, a and b; ... Kevent based network AIO already handle it. ... Kevent network AIO is completely different from network tree allocator. ... it only provides a memory. ...
    (Linux-Kernel)
  • Re: [RFC][PATCH 0/9] Network receive deadlock prevention for NBD
    ... Convergence of network and storage paths" ... On your site where you explain the Network Tree Allocator: ... You only test the fragmentation scenario with the full scale of sizes. ... power-of-two (I use 32 bytes alignemnt, as the smallest one which SLAB ...
    (Linux-Kernel)
  • Re: [RFC][PATCH 0/9] Network receive deadlock prevention for NBD
    ... hack openssh code to be able to allow it to use reserve when there is not enough memory. ... kernel services, and the continued well being of the kernel, not ... And even if you will cover all kernel-only network allocations, ... but if allocator depends on main system's memory ...
    (Linux-Kernel)
  • Re: [RFC][PATCH 0/9] Network receive deadlock prevention for NBD
    ... Convergence of network and storage paths" ... On your site where you explain the Network Tree Allocator: ... power-of-two (I use 32 bytes alignemnt, as the smallest one which SLAB ... Each page can easily have several packets inside. ...
    (Linux-Kernel)