--On 27 September 2011 20:26:48 -0700 Adam Cozzette <[email protected]> wrote:
> So it seems to me that the deadlock situation is essentially the same > whether you're swapping to a block device or just writing out dirty > pages. Or am I mistaken about that? Is this something that is so unlikely > to occur that there is no point in worrying about it? I think it is *not* so unlikely there is no point worrying about it. My excuse to date for not worrying about it is that in our application nbd is accessed directly by hypervisors, so I /think/ we don't suffer from that issue. IIRC memory allocation on stock nbd-server in the write path is minimal (but minimal != zero). Now you mention it, I am trying to work out how it works even with a remote server. If all the pages are dirty waiting to be written to nbd, and a write is started which causes a GFP_KERNEL allocation to allocate the skbuff for the tcp packet, and there is no free memory, I am not sure how any progress is made. I get the feeling this at least must be soluble, or nfs and iscsi would be dead in the water. -- Alex Bligh ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 _______________________________________________ Nbd-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/nbd-general
