> > > > > I think adding kind of schedule() will not make things worse and in corner > > cases could prevent a power drain by CPU. It is important for mobile devices. > > I suspect you mean schedule_timeout here? Or cond_resched? I went with a > later for now, I do not have a good idea for how to long to sleep here. > I am more than happy to change to to a sleep though. > cond_resched() reschedules only if TIF_NEED_RESCHED is raised what is not good here. Because in our case we know that we definitely would like to take a breath. Therefore invoking the schedule() is more suitable here. It will give a CPU time to another waiting process(if exists) in any case putting the "current" one to the tail. As for adding a delay. I am not sure about for how long to delay or i would say i do not see a good explanation why for example we delay for 10 milliseconds or so. > > As for vmap space, it can be that a user specifies a short range that does > > not contain any free area. In that case we might never return back to a caller. > > This is to be expected. The caller cannot fail and if it would be > looping around vmalloc it wouldn't return anyway. > > > Maybe add a good comment something like: think what you do when deal with the > > __vmalloc_node_range() and __GFP_NOFAIL? > > We have a generic documentation for gfp flags and __GFP_NOFAIL is > docuemented to "The allocation could block indefinitely but will never > return with failure." We are discussing improvements for the generic > documentation in another thread [1] and we will likely extend it so I > suspect we do not have to repeat drawbacks here again. > > [1] http://lkml.kernel.org/r/163184741778.29351.16920832234899124642.stgit@noble.brown > > Anyway the gfp mask description and constrains for vmalloc are not > documented. I will add a new patch to fill that gap and send it as a > reply to this one > This is really good. People should be prepared for a case when it never returns back to a caller :) -- Uladzislau Rezki
