> Correct me if I'm wrong Tejun, but the key issues are: > > All WQ_MEM_RECLAIM work queues are eligible to be run when the > machine > is under extreme memory pressure and attempting to reclaim memory. That > means that the workqueue: > > 1) MUST not perform any GFP_ATOMIC allocations as this could deadlock The send engine code WILL do a GFP_ATOMIC allocation but the code handles failure as will any other resource shortage. > 2) SHOULD not rely on any GFP_KERNEL allocations as these may fail There are no GFP_KERNEL allocations in the send engine code. > 3) MUST complete without blocking All resource blockages are handled by queuing the current QP being serviced by the send engine for and interrupt to wake that QP up via the send engine. > 4) SHOULD ideally always make some sort of forward progress if at all > possible without needing memory allocations to do so > As noted above. > Mike, does hfi1_do_send() meet these requirements? If not, we should > not be putting WQ_MEM_RECLAIM on it, and instead should find another > solution to the current trace issue. > I'm not sure I understand the 1) above. Tejun, can you elaborate? Mike
