On Wed, Aug 26, 2020 at 08:37:06AM +1000, Dave Chinner wrote: > On Tue, Aug 25, 2020 at 04:34:58PM +0200, Carlos Maiolino wrote: > > This patch aims to replace kmem_zalloc_large() with global kernel memory > > API. So, all its callers are now using kvzalloc() directly, so kmalloc() > > fallsback to vmalloc() automatically. > > > > __GFP_RETRY_MAYFAIL has been set because according to memory documentation, > > it should be used in case kmalloc() is preferred over vmalloc(). > > > > Patch survives xfstests with large (32GiB) and small (4GiB) RAM memory amounts. > > > > Signed-off-by: Carlos Maiolino <cmaiolino@xxxxxxxxxx> > > --- > > fs/xfs/kmem.h | 6 ------ > > fs/xfs/scrub/symlink.c | 4 +++- > > fs/xfs/xfs_acl.c | 3 ++- > > fs/xfs/xfs_ioctl.c | 5 +++-- > > fs/xfs/xfs_rtalloc.c | 3 ++- > > 5 files changed, 10 insertions(+), 11 deletions(-) > > > > I'm not entirely sure passing __GFP_RETRY_MAYFAIL is the right thing to do here, > > but since current api attempts a kmalloc before falling back to vmalloc, it > > seems to be correct to pass it. > > I don't think __GFP_RETRY_MAYFAIL is necessary. If the allocation is > larger than ALLOC_ORDER_COSTLY (8 pages, I think) then kmalloc() > will fail rather than retry forever and then it falls back to > vmalloc. Hence I don't think we need to tell the kmalloc() it needs > to fail large allocations if it can't make progress... > > Cheers, Thanks Dave! If nobody has any other comment, I'll submit a version without RETRY_MAYFAIL later today. cheers. > > Dave. > -- > Dave Chinner > david@xxxxxxxxxxxxx > -- Carlos
