On Thu, Apr 02, 2015 at 01:57:10PM -0700, Nicholas A. Bellinger wrote: > > mempools are for I/O path that make guaranteed progress. While the > > callers of core_enable_device_list_for_node are in the control path, > > and not in a very deep callstack, fairly shallow below the configfs > > interface. This is not a use case for mempools, as there is no need > > to guarantee progress in deep I/O callstacks. > > > > I was more concerned about the creation of se_dev_entry for dynamically > generated se_node_acl in the login path. > > Having to back out everything upon se_dev_entry allocation failure is > annoying. But unless you specificly pre-create the number of entries that core_dev_add_lun may create that's the only way to handle it. mempool rely on the fact the objects get freed to the mempool again to make forward progress, which isn't the case for a lon-lived se_dev_entry allocation. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
