On Tue 26-03-19 18:08:17, Baoquan He wrote: > On 03/26/19 at 10:29am, Michal Hocko wrote: > > On Tue 26-03-19 17:02:25, Baoquan He wrote: > > > Reorder the allocation of usemap and memmap since usemap allocation > > > is much simpler and easier. Otherwise hard work is done to make > > > memmap ready, then have to rollback just because of usemap allocation > > > failure. > > > > Is this really worth it? I can see that !VMEMMAP is doing memmap size > > allocation which would be 2MB aka costly allocation but we do not do > > __GFP_RETRY_MAYFAIL so the allocator backs off early. > > In !VMEMMAP case, it truly does simple allocation directly. surely > usemap which size is 32 is smaller. So it doesn't matter that much who's > ahead or who's behind. However, this benefit a little in VMEMMAP case. How does it help there? The failure should be even much less probable there because we simply fall back to a small 4kB pages and those essentially never fail. > And this make code a little cleaner, e.g the error handling at the end > is taken away. > > > > > > And also check if section is present earlier. Then don't bother to > > > allocate usemap and memmap if yes. > > > > Moving the check up makes some sense. > > > > > Signed-off-by: Baoquan He <bhe@xxxxxxxxxx> > > > > The patch is not incorrect but I am wondering whether it is really worth > > it for the current code base. Is it fixing anything real or it is a mere > > code shuffling to please an eye? > > It's not a fixing, just a tiny code refactorying inside > sparse_add_one_section(), seems it doesn't worsen thing if I got the > !VMEMMAP case correctly, not quite sure. I am fine to drop it if it's > not worth. I could miss something in different cases. Well, I usually prefer to not do micro-optimizations in a code that really begs for a much larger surgery. There are other people working on the code and patches like these might get into the way and cuase conflicts without a very good justification. -- Michal Hocko SUSE Labs
