http://lwn.net/Articles/144273/ This is a special feed containing comments posted to the individual LWN article titled "Kernel Summit 2005: Convergence of network and storage paths". hourly 2 http://lwn.net/Articles/145829/rss 2005-08-02T02:36:13+00:00 mmarq "... this problem is hard, and people have been trying to solve it for decades. Rather than continuing to beat our heads against the wall, wouldn't it just be better to tell people to buy a local disk? Diskless systems were shown to be a bad idea back in the 1980's; why repeat the same mistakes 20 years later? "<br> <p> Belive it could be easly solved when "things" develop to the recognition that the intire Network Subsystem could be offloaded to their own complete systems with a NUP(network CPU) and local memory and IO management, in exactly the same way that happened with graphics/video subsystems.<br> <p> A NIC(or mobo integrated) *should* be in the same form of a Graphic Adapter... a whole system in itself!<br> <p> The sorry thing to forsee is that it would require close cooperation with hardware manufactors, the same as the graphic world require,... and there is a area where Linux/FOSS perform very badly.<br> http://lwn.net/Articles/144717/rss 2005-07-22T18:57:46+00:00 giraffedata There really is no amount of memory you can simply set aside in an emergency pool to avoid these memory deadlocks. You have to reserve memory for a particular thread of execution; the more threads, the more memory. And you have to reserve the memory and other resources in a fixed order. I.e. make sure you never need Level N or N+1 resource in order to proceed to where you can release Level N resource you are already holding. <p> This is where ISCSI has a special problem. Linux has been designed so that the network is a higher layer than memory management. A network function can request MM services, and an MM function can't request network services. But in ISCSI, MM does in fact need network services (to give you memory, MM has to clean dirty memory, which means it needs block services, which need network services). <p> The only fix is to put the resource grabbing back in order -- make sure a process reserves all of the memory it needs to finish what it's doing at one time, and somehow makes it available to the functions further down its stack that need it. This is a nontrivial extension of various kernel services. <p> As for the problem that a process' memory requirement changes without any kernel participation when the process dirties memory: The kernel has to make the reservation at the time it adds a dirtyable page to the process' address space. <p> Throttling, like an arbitrary emergency reserve, mitigates but does not solve the deadlock problem. Throttling is where you choke off new work at its source. It can help performance and fairness. But to avoid deadlock, you have to push the work back from the destination: don't accept any piece of work until you've reserved all the resources needed to guarantee you'll complete it. It has the same slowing effect, but is fundamentally different from throttling.