On Thu, Oct 11, 2012 at 12:20 AM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > This makes a lot of sense. It remains to be seen whether you can > convince the people on LKML to allow a new field to be added to > task_struct. If the idea can fix the kind of problem, I mean other block devices might have the problem too, it should be more persuasive. Also the flag may be added to 'struct thread_info' too, which is on stack space. > This cries out for an inline function because it is repeated in so many > places -- wherever gfp_allowed_mask is used. Yes, it should be a macro. On Thu, Oct 11, 2012 at 2:29 AM, Oliver Neukum <oneukum@xxxxxxx> wrote: > Very clever. However, how hot are the code paths you are adding this to? If it can solve this kind of problem on block devices, we can measure the performance effect of it, which only adds one extra word read and one AND operation in the hot path. On the other hand, the hotter the code path is, the more difficult the GFP_NOIO solution becomes. Thanks, -- Ming Lei -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
