On Wed, 2017-02-08 at 20:14 +0000, Bart Van Assche wrote: > On Wed, 2017-02-08 at 11:06 -0800, Nicholas A. Bellinger wrote: > > Adding a second atomic_t emulating a kref on top of the existing > > se_cmd->cmd_kref, and then doing a complete_all() for the special TMR > > path in the normal fast-path is not going to be acceptable. > > I don't see why that approach would not be acceptable. My patches remove > more atomic operations than the number of new atomic operations that are > introduced in the hot path so these patches will improve performance. You've got less than 24 hours of soak time after I highlighted a rather fundamental flaw in the v2 approach to the first order issue of how ABORT_TASK and LUN_RESET function when backend I/O is taking an extended amount of time to complete. This tells me your entire manual testing of these code-path thus far been rather useless. Have you tested the second and third order issues at scale yet to ensure these changes don't introduce regressions, vs. what we know is stable in mainline..? If so, how many LUNs, nodes, and how many occurrences of each order issue..? The point is you need to remove the target patches from linux-next that don't have reviews and answer to and understand the feedback I've given you to think about, considering it's taken years to get this particular area of the code stable across the drivers in mainline. Beyond that, if you want to make larger changes you need to really consider getting dedicated QA resources and/or automation setup from your employer to test them for extended period of times, in stressful conditions. Trying to manually test these large changes at small scale in your spare time, efficiently avoiding the interesting code-paths until the obvious flaws where pointed out on the list is unacceptable. -- To unsubscribe from this list: send the line "unsubscribe target-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
