> On Fri 29-10-21 16:05:32, Uladzislau Rezki wrote: > [...] > > > OK, this looks easier from the code reading but isn't it quite wasteful > > > to throw all the pages backing the area (all of them allocated as > > > __GFP_NOFAIL) just to then fail to allocate few page tables pages and > > > drop all of that on the floor (this will happen in __vunmap AFAICS). > > > > > > I mean I do not care all that strongly but it seems to me that more > > > changes would need to be done here and optimizations can be done on top. > > > > > > Is this something you feel strongly about? > > > > > Will try to provide some motivations :) > > > > It depends on how to look at it. My view is as follows a more simple code > > is preferred. It is not considered as a hot path and it is rather a corner > > case to me. > > Yes, we are definitely talking about corner cases here. Even GFP_KERNEL > allocations usually do not fail. > > > I think "unwinding" has some advantage. At least one motivation > > is to release a memory(on failure) before a delay that will prevent holding > > of extra memory in case of __GFP_NOFAIL infinitelly does not succeed, i.e. > > if a process stuck due to __GFP_NOFAIL it does not "hold" an extra memory > > forever. > > Well, I suspect this is something that we can disagree on and both of us > would be kinda right. I would see it as throwing baby out with the > bathwater. The vast majority of the memory will be in the area pages and > sacrificing that just to allocate few page tables or whatever that might > fail in that code path is just a lot of cycles wasted. > We are not talking about performance, no sense to measure cycles here :) > > So unless you really feel strongly about this then I would stick with > this approach. > I have raised one concern. The memory resource is shared between all process in case of __GFP_NOFAIL it might be that we never return back to user in that scenario i prefer to release hold memory for other needs instead of keeping it for nothing. If you think it is not a problem, then i do not have much to say. -- Vlad Rezki
