kvmalloc

From: Michal Hocko <[email protected]>

Using kmalloc with the vmalloc fallback for larger allocations is a common pattern in the kernel code. Yet we do not have any common helper for that and so users have invented their own helpers. Some of them are really creative when doing so. Let's just add kv[mz]alloc and make sure it is implemented properly. This implementation makes sure to not make a large memory pressure for > PAGE_SZE requests (__GFP_NORETRY) and also to not warn about allocation failures. This also rules out the OOM killer as the vmalloc is a more approapriate fallback than a disruptive user visible action.

This patch also changes some existing users and removes helpers which are specific for them. In some cases this is not possible (e.g. ext4_kvmalloc, libcfs_kvzalloc, __aa_kvmalloc) because those seems to be broken and require GFP_NO{FS,IO} context which is not vmalloc compatible in general (note that the page table allocation is GFP_KERNEL). Those need to be fixed separately.

apparmor has already claimed kv[mz]alloc so remove those and use __aa_kvmalloc instead to prevent from the naming clashes.

Changes since v3
- add ipc_alloc

Changes since v2
- s@WARN_ON@WARN_ON_ONCE@ as per Vlastimil
- do not fallback to vmalloc for size = PAGE_SIZE as per Vlastimil

Changes since v1
- define __vmalloc_node_flags for CONFIG_MMU=n

Cc Anatoly Stepanov <[email protected]>

Cc Paolo Bonzini <[email protected]>

Cc Mike Snitzer <[email protected]>

Cc "Michael S. Tsirkin" <[email protected]>

Cc "Theodore Ts'o" <[email protected]>

Reviewed-by Andreas Dilger <[email protected]> # ext4 part

Acked-by Vlastimil Babka <[email protected]>

Signed-off-by Michal Hocko <[email protected]>

---
 arch/x86/kvm/lapic.c                 |  4 ++--
 arch/x86/kvm/page_track.c            |  4 ++--
 arch/x86/kvm/x86.c                   |  4 ++--
 drivers/md/dm-stats.c                |  7 +-----
 fs/ext4/mballoc.c                    |  2 +-
 fs/ext4/super.c                      |  4 ++--
 fs/f2fs/f2fs.h                       | 20 -----------------
 fs/f2fs/file.c                       |  4 ++--
 fs/f2fs/segment.c                    | 14 ++++++------
 fs/seq_file.c                        | 16 +-------------
 include/linux/kvm_host.h             |  2 --
 include/linux/mm.h                   | 14 ++++++++++++
 include/linux/vmalloc.h              |  1 +
 ipc/util.c                           |  7 +-----
 mm/nommu.c                           |  5 +++++
 mm/util.c                            | 42 ++++++++++++++++++++++++++++++++++++
 mm/vmalloc.c                         |  2 +-
 security/apparmor/apparmorfs.c       |  2 +-
 security/apparmor/include/apparmor.h | 10 ---------
 security/apparmor/match.c            |  2 +-
 virt/kvm/kvm_main.c                  | 18 +++-------------
 21 files changed, 89 insertions(+), 95 deletions(-)

arch/x86/kvm/lapic.c +2 -2

index 5fe290c1b7d8..daf114c3b8ad 100644
@@ -167,8 +167,8 @@ static void recalculate_apic_map(struct kvm *kvm)
 		if (kvm_apic_present(vcpu))
 			max_id = max(max_id, kvm_apic_id(vcpu->arch.apic));
 
-	new = kvm_kvzalloc(sizeof(struct kvm_apic_map) +
-	                   sizeof(struct kvm_lapic *) * ((u64)max_id + 1));
+	new = kvzalloc(sizeof(struct kvm_apic_map) +
+	                   sizeof(struct kvm_lapic *) * ((u64)max_id + 1), GFP_KERNEL);
 
 	if (!new)
 		goto out;

arch/x86/kvm/page_track.c +2 -2

index 4a1c13eaa518..d46663e655b0 100644
@@ -38,8 +38,8 @@ int kvm_page_track_create_memslot(struct kvm_memory_slot *slot,
 	int  i;
 
 	for (i = 0; i < KVM_PAGE_TRACK_MAX; i++) {
-		slot->arch.gfn_track[i] = kvm_kvzalloc(npages *
-					    sizeof(*slot->arch.gfn_track[i]));
+		slot->arch.gfn_track[i] = kvzalloc(npages *
+					    sizeof(*slot->arch.gfn_track[i]), GFP_KERNEL);
 		if (!slot->arch.gfn_track[i])
 			goto track_free;
 	}

arch/x86/kvm/x86.c +2 -2

index 51ccfe08e32f..ba55bc338f25 100644
@@ -8082,13 +8082,13 @@ int kvm_arch_create_memslot(struct kvm *kvm, struct kvm_memory_slot *slot,
 				      slot->base_gfn, level) + 1;
 
 		slot->arch.rmap[i] =
-			kvm_kvzalloc(lpages * sizeof(*slot->arch.rmap[i]));
+			kvzalloc(lpages * sizeof(*slot->arch.rmap[i]), GFP_KERNEL);
 		if (!slot->arch.rmap[i])
 			goto out_free;
 		if (i == 0)
 			continue;
 
-		linfo = kvm_kvzalloc(lpages * sizeof(*linfo));
+		linfo = kvzalloc(lpages * sizeof(*linfo), GFP_KERNEL);
 		if (!linfo)
 			goto out_free;
 

drivers/md/dm-stats.c +1 -6

index 38b05f23b96c..674f9a1686f7 100644
@@ -146,12 +146,7 @@ static void *dm_kvzalloc(size_t alloc_size, int node)
 	if (!claim_shared_memory(alloc_size))
 		return NULL;
 
-	if (alloc_size <= KMALLOC_MAX_SIZE) {
-		p = kzalloc_node(alloc_size, GFP_KERNEL | __GFP_NORETRY | __GFP_NOMEMALLOC | __GFP_NOWARN, node);
-		if (p)
-			return p;
-	}
-	p = vzalloc_node(alloc_size, node);
+	p = kvzalloc_node(alloc_size, GFP_KERNEL | __GFP_NOMEMALLOC, node);
 	if (p)
 		return p;
 

fs/ext4/mballoc.c +1 -1

index d9fd184b049e..31a761dd76f5 100644
@@ -2381,7 +2381,7 @@ int ext4_mb_alloc_groupinfo(struct super_block *sb, ext4_group_t ngroups)
 		return 0;
 
 	size = roundup_pow_of_two(sizeof(*sbi->s_group_info) * size);
-	new_groupinfo = ext4_kvzalloc(size, GFP_KERNEL);
+	new_groupinfo = kvzalloc(size, GFP_KERNEL);
 	if (!new_groupinfo) {
 		ext4_msg(sb, KERN_ERR, "can't allocate buddy meta group");
 		return -ENOMEM;

fs/ext4/super.c +2 -2

index 66845a08a87a..c65fe19a2a4f 100644
@@ -2116,7 +2116,7 @@ int ext4_alloc_flex_bg_array(struct super_block *sb, ext4_group_t ngroup)
 		return 0;
 
 	size = roundup_pow_of_two(size * sizeof(struct flex_groups));
-	new_groups = ext4_kvzalloc(size, GFP_KERNEL);
+	new_groups = kvzalloc(size, GFP_KERNEL);
 	if (!new_groups) {
 		ext4_msg(sb, KERN_ERR, "not enough memory for %d flex groups",
 			 size / (int) sizeof(struct flex_groups));

@@ -3850,7 +3850,7 @@ static int ext4_fill_super(struct super_block *sb, void *data, int silent)
 			goto failed_mount;
 		}
 	}
-	sbi->s_group_desc = ext4_kvmalloc(db_count *
+	sbi->s_group_desc = kvmalloc(db_count *
 					  sizeof(struct buffer_head *),
 					  GFP_KERNEL);
 	if (sbi->s_group_desc == NULL) {

fs/f2fs/f2fs.h +0 -20

index 2da8c3aa0ce5..4130df0a8e64 100644
@@ -1929,26 +1929,6 @@ static inline void *f2fs_kmalloc(struct f2fs_sb_info *sbi,
 	return kmalloc(size, flags);
 }
 
-static inline void *f2fs_kvmalloc(size_t size, gfp_t flags)
-{
-	void *ret;
-
-	ret = kmalloc(size, flags | __GFP_NOWARN);
-	if (!ret)
-		ret = __vmalloc(size, flags, PAGE_KERNEL);
-	return ret;
-}
-
-static inline void *f2fs_kvzalloc(size_t size, gfp_t flags)
-{
-	void *ret;
-
-	ret = kzalloc(size, flags | __GFP_NOWARN);
-	if (!ret)
-		ret = __vmalloc(size, flags | __GFP_ZERO, PAGE_KERNEL);
-	return ret;
-}
-
 #define get_inode_mode(i) \
 	((is_inode_flag_set(i, FI_ACL_MODE)) ? \
 	 (F2FS_I(i)->i_acl_mode) : ((i)->i_mode))

fs/f2fs/file.c +2 -2

index 49f10dce817d..fb2e0c156135 100644
@@ -1013,11 +1013,11 @@ static int __exchange_data_block(struct inode *src_inode,
 	while (len) {
 		olen = min((pgoff_t)4 * ADDRS_PER_BLOCK, len);
 
-		src_blkaddr = f2fs_kvzalloc(sizeof(block_t) * olen, GFP_KERNEL);
+		src_blkaddr = kvzalloc(sizeof(block_t) * olen, GFP_KERNEL);
 		if (!src_blkaddr)
 			return -ENOMEM;
 
-		do_replace = f2fs_kvzalloc(sizeof(int) * olen, GFP_KERNEL);
+		do_replace = kvzalloc(sizeof(int) * olen, GFP_KERNEL);
 		if (!do_replace) {
 			kvfree(src_blkaddr);
 			return -ENOMEM;

fs/f2fs/segment.c +7 -7

index 0738f48293cc..c50c883bfc1a 100644
@@ -2286,13 +2286,13 @@ static int build_sit_info(struct f2fs_sb_info *sbi)
 
 	SM_I(sbi)->sit_info = sit_i;
 
-	sit_i->sentries = f2fs_kvzalloc(MAIN_SEGS(sbi) *
+	sit_i->sentries = kvzalloc(MAIN_SEGS(sbi) *
 					sizeof(struct seg_entry), GFP_KERNEL);
 	if (!sit_i->sentries)
 		return -ENOMEM;
 
 	bitmap_size = f2fs_bitmap_size(MAIN_SEGS(sbi));
-	sit_i->dirty_sentries_bitmap = f2fs_kvzalloc(bitmap_size, GFP_KERNEL);
+	sit_i->dirty_sentries_bitmap = kvzalloc(bitmap_size, GFP_KERNEL);
 	if (!sit_i->dirty_sentries_bitmap)
 		return -ENOMEM;
 

@@ -2318,7 +2318,7 @@ static int build_sit_info(struct f2fs_sb_info *sbi)
 		return -ENOMEM;
 
 	if (sbi->segs_per_sec > 1) {
-		sit_i->sec_entries = f2fs_kvzalloc(MAIN_SECS(sbi) *
+		sit_i->sec_entries = kvzalloc(MAIN_SECS(sbi) *
 					sizeof(struct sec_entry), GFP_KERNEL);
 		if (!sit_i->sec_entries)
 			return -ENOMEM;

@@ -2364,12 +2364,12 @@ static int build_free_segmap(struct f2fs_sb_info *sbi)
 	SM_I(sbi)->free_info = free_i;
 
 	bitmap_size = f2fs_bitmap_size(MAIN_SEGS(sbi));
-	free_i->free_segmap = f2fs_kvmalloc(bitmap_size, GFP_KERNEL);
+	free_i->free_segmap = kvmalloc(bitmap_size, GFP_KERNEL);
 	if (!free_i->free_segmap)
 		return -ENOMEM;
 
 	sec_bitmap_size = f2fs_bitmap_size(MAIN_SECS(sbi));
-	free_i->free_secmap = f2fs_kvmalloc(sec_bitmap_size, GFP_KERNEL);
+	free_i->free_secmap = kvmalloc(sec_bitmap_size, GFP_KERNEL);
 	if (!free_i->free_secmap)
 		return -ENOMEM;
 

@@ -2537,7 +2537,7 @@ static int init_victim_secmap(struct f2fs_sb_info *sbi)
 	struct dirty_seglist_info *dirty_i = DIRTY_I(sbi);
 	unsigned int bitmap_size = f2fs_bitmap_size(MAIN_SECS(sbi));
 
-	dirty_i->victim_secmap = f2fs_kvzalloc(bitmap_size, GFP_KERNEL);
+	dirty_i->victim_secmap = kvzalloc(bitmap_size, GFP_KERNEL);
 	if (!dirty_i->victim_secmap)
 		return -ENOMEM;
 	return 0;

@@ -2559,7 +2559,7 @@ static int build_dirty_segmap(struct f2fs_sb_info *sbi)
 	bitmap_size = f2fs_bitmap_size(MAIN_SEGS(sbi));
 
 	for (i = 0; i < NR_DIRTY_TYPE; i++) {
-		dirty_i->dirty_segmap[i] = f2fs_kvzalloc(bitmap_size, GFP_KERNEL);
+		dirty_i->dirty_segmap[i] = kvzalloc(bitmap_size, GFP_KERNEL);
 		if (!dirty_i->dirty_segmap[i])
 			return -ENOMEM;
 	}

fs/seq_file.c +1 -15

index ca69fb99e41a..dc7c2be963ed 100644
@@ -25,21 +25,7 @@ static void seq_set_overflow(struct seq_file *m)
 
 static void *seq_buf_alloc(unsigned long size)
 {
-	void *buf;
-	gfp_t gfp = GFP_KERNEL;
-
-	/*
-	 * For high order allocations, use __GFP_NORETRY to avoid oom-killing -
-	 * it's better to fall back to vmalloc() than to kill things.  For small
-	 * allocations, just use GFP_KERNEL which will oom kill, thus no need
-	 * for vmalloc fallback.
-	 */
-	if (size > PAGE_SIZE)
-		gfp |= __GFP_NORETRY | __GFP_NOWARN;
-	buf = kmalloc(size, gfp);
-	if (!buf && size > PAGE_SIZE)
-		buf = vmalloc(size);
-	return buf;
+	return kvmalloc(size, GFP_KERNEL);
 }
 
 /**

include/linux/kvm_host.h +0 -2

index 1c5190dab2c1..00e6f93d1ee0 100644
@@ -768,8 +768,6 @@ void kvm_arch_check_processor_compat(void *rtn);
 int kvm_arch_vcpu_runnable(struct kvm_vcpu *vcpu);
 int kvm_arch_vcpu_should_kick(struct kvm_vcpu *vcpu);
 
-void *kvm_kvzalloc(unsigned long size);
-
 #ifndef __KVM_HAVE_ARCH_VM_ALLOC
 static inline struct kvm *kvm_arch_alloc_vm(void)
 {

include/linux/mm.h +14 -0

index fe6b4036664a..55fd570c3e1e 100644
@@ -484,6 +484,20 @@ static inline int is_vmalloc_or_module_addr(const void *x)
 }
 #endif
 
+extern void *kvmalloc_node(size_t size, gfp_t flags, int node);
+static inline void *kvmalloc(size_t size, gfp_t flags)
+{
+	return kvmalloc_node(size, flags, NUMA_NO_NODE);
+}
+static inline void *kvzalloc_node(size_t size, gfp_t flags, int node)
+{
+	return kvmalloc_node(size, flags | __GFP_ZERO, node);
+}
+static inline void *kvzalloc(size_t size, gfp_t flags)
+{
+	return kvmalloc(size, flags | __GFP_ZERO);
+}
+
 extern void kvfree(const void *addr);
 
 static inline atomic_t *compound_mapcount_ptr(struct page *page)

include/linux/vmalloc.h +1 -0

index d68edffbf142..46991ad3ddd5 100644
@@ -80,6 +80,7 @@ extern void *__vmalloc_node_range(unsigned long size, unsigned long align,
 			unsigned long start, unsigned long end, gfp_t gfp_mask,
 			pgprot_t prot, unsigned long vm_flags, int node,
 			const void *caller);
+extern void *__vmalloc_node_flags(unsigned long size, int node, gfp_t flags);
 
 extern void vfree(const void *addr);
 extern void vfree_atomic(const void *addr);

ipc/util.c +1 -6

index 798cad18dd87..74c2adc62086 100644
@@ -403,12 +403,7 @@ void ipc_rmid(struct ipc_ids *ids, struct kern_ipc_perm *ipcp)
  */
 void *ipc_alloc(int size)
 {
-	void *out;
-	if (size > PAGE_SIZE)
-		out = vmalloc(size);
-	else
-		out = kmalloc(size, GFP_KERNEL);
-	return out;
+	return kvmalloc(size, GFP_KERNEL);
 }
 
 /**

mm/nommu.c +5 -0

index 24f9f5f39145..f1927890f75e 100644
@@ -236,6 +236,11 @@ void *__vmalloc(unsigned long size, gfp_t gfp_mask, pgprot_t prot)
 }
 EXPORT_SYMBOL(__vmalloc);
 
+void *__vmalloc_node_flags(unsigned long size, int node, gfp_t flags)
+{
+	return __vmalloc(size, flags, PAGE_KERNEL);
+}
+
 void *vmalloc_user(unsigned long size)
 {
 	void *ret;

mm/util.c +0 -0

index 3cb2164f4099..7e0c240b5760 100644

mm/util.c +10 -0

+ */
+void *kvmalloc_node(size_t size, gfp_t flags, int node)
+{
+	gfp_t kmalloc_flags = flags;
+	void *ret;
+
+	/*
+	 * vmalloc uses GFP_KERNEL for some internal allocations (e.g page tables)
+	 * so the given set of flags has to be compatible.
+	 */

mm/util.c +12 -0

+
+	/*
+	 * It doesn't really make sense to fallback to vmalloc for sub page
+	 * requests
+	 */
+	if (ret || size <= PAGE_SIZE)
+		return ret;
+
+	return __vmalloc_node_flags(size, node, flags);
+}
+EXPORT_SYMBOL(kvmalloc_node);
+
 void kvfree(const void *addr)
 {
 	if (is_vmalloc_addr(addr))

mm/vmalloc.c +1 -1

index 3ca82d44edd3..1039b1230889 100644
@@ -1757,7 +1757,7 @@ void *__vmalloc(unsigned long size, gfp_t gfp_mask, pgprot_t prot)
 }
 EXPORT_SYMBOL(__vmalloc);
 
-static inline void *__vmalloc_node_flags(unsigned long size,
+void *__vmalloc_node_flags(unsigned long size,
 					int node, gfp_t flags)
 {
 	return __vmalloc_node(size, 1, flags, PAGE_KERNEL,

security/apparmor/apparmorfs.c +1 -1

index 5923d5665209..83789a03379f 100644
@@ -100,7 +100,7 @@ static char *aa_simple_write_to_buffer(int op, const char __user *userbuf,
 		return ERR_PTR(-EACCES);
 
 	/* freed by caller to simple_write_to_buffer */
-	data = kvmalloc(alloc_size);
+	data = __aa_kvmalloc(alloc_size, 0);
 	if (data == NULL)
 		return ERR_PTR(-ENOMEM);
 

security/apparmor/include/apparmor.h +0 -10

index 5d721e990876..c88fb0ebc756 100644
@@ -68,16 +68,6 @@ char *aa_split_fqname(char *args, char **ns_name);
 void aa_info_message(const char *str);
 void *__aa_kvmalloc(size_t size, gfp_t flags);
 
-static inline void *kvmalloc(size_t size)
-{
-	return __aa_kvmalloc(size, 0);
-}
-
-static inline void *kvzalloc(size_t size)
-{
-	return __aa_kvmalloc(size, __GFP_ZERO);
-}
-
 /* returns 0 if kref not incremented */
 static inline int kref_get_not0(struct kref *kref)
 {

security/apparmor/match.c +1 -1

index 3f900fcca8fb..55f6ae0067a3 100644
@@ -61,7 +61,7 @@ static struct table_header *unpack_table(char *blob, size_t bsize)
 	if (bsize < tsize)
 		goto out;
 
-	table = kvzalloc(tsize);
+	table = __aa_kvmalloc(tsize, __GFP_ZERO);
 	if (table) {
 		table->td_id = th.td_id;
 		table->td_flags = th.td_flags;

virt/kvm/kvm_main.c +3 -16

index 482612b4e496..dbfe0e79232d 100644
@@ -502,7 +502,7 @@ static struct kvm_memslots *kvm_alloc_memslots(void)
 	int i;
 	struct kvm_memslots *slots;
 
-	slots = kvm_kvzalloc(sizeof(struct kvm_memslots));
+	slots = kvzalloc(sizeof(struct kvm_memslots), GFP_KERNEL);
 	if (!slots)
 		return NULL;
 

@@ -685,18 +685,6 @@ static struct kvm *kvm_create_vm(unsigned long type)
 	return ERR_PTR(r);
 }
 
-/*
- * Avoid using vmalloc for a small buffer.
- * Should not be used when the size is statically known.
- */
-void *kvm_kvzalloc(unsigned long size)
-{
-	if (size > PAGE_SIZE)
-		return vzalloc(size);
-	else
-		return kzalloc(size, GFP_KERNEL);
-}
-
 static void kvm_destroy_devices(struct kvm *kvm)
 {
 	struct kvm_device *dev, *tmp;

@@ -775,7 +763,7 @@ static int kvm_create_dirty_bitmap(struct kvm_memory_slot *memslot)
 {
 	unsigned long dirty_bytes = 2 * kvm_dirty_bitmap_bytes(memslot);
 
-	memslot->dirty_bitmap = kvm_kvzalloc(dirty_bytes);
+	memslot->dirty_bitmap = kvzalloc(dirty_bytes, GFP_KERNEL);
 	if (!memslot->dirty_bitmap)
 		return -ENOMEM;
 

@@ -995,7 +983,7 @@ int __kvm_set_memory_region(struct kvm *kvm,
 			goto out_free;
 	}
 
-	slots = kvm_kvzalloc(sizeof(struct kvm_memslots));
+	slots = kvzalloc(sizeof(struct kvm_memslots), GFP_KERNEL);
 	if (!slots)
 		goto out_free;
 	memcpy(slots, __kvm_memslots(kvm, as_id), sizeof(struct kvm_memslots));
--

2.11.0

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

On 01/12/2017 07:37 AM, Michal Hocko wrote:

mm/util.c unsigned long vm_mmap(struct file *file, unsigned long addr, · line 328

Quoted 10 lines

mm/util.c +2 -0

index 3cb2164f4099..7e0c240b5760 100644
@@ -324,6 +324,48 @@ unsigned long vm_mmap(struct file *file, unsigned long addr,
 }
 EXPORT_SYMBOL(vm_mmap);
 
+/**
+ * kvmalloc_node - allocate contiguous memory from SLAB with vmalloc fallback

Hi Michal,

How about this wording instead:

kvmalloc_node - attempt to allocate physically contiguous memory, but upon failure, fall back to non-contiguous (vmalloc) allocation.

mm/util.c unsigned long vm_mmap(struct file *file, unsigned long addr, · line 336

Quoted 8 lines

mm/util.c +8 -0

+ * @size: size of the request.
+ * @flags: gfp mask for the allocation - must be compatible (superset) with GFP_KERNEL.
+ * @node: numa node to allocate from
+ *
+ * Uses kmalloc to get the memory but if the allocation fails then falls back
+ * to the vmalloc allocator. Use kvfree for freeing the memory.
+ *
+ * Reclaim modifiers - __GFP_NORETRY, __GFP_REPEAT and __GFP_NOFAIL are not supported

Is that "Reclaim modifiers" line still true, or is it a leftover from an earlier approach? I am having trouble reconciling it with rest of the patchset, because:

a) the flags argument below is effectively passed on to either kmalloc_node (possibly adding, but not removing flags), or to __vmalloc_node_flags.

b) In patch 6/6, you are in fact passing in __GFP_REPEAT to the wrappers (kvzalloc, for example), and again, only adding, not removing flags.

Quoted 16 lines

mm/util.c +16 -0

+ */
+void *kvmalloc_node(size_t size, gfp_t flags, int node)
+{
+	gfp_t kmalloc_flags = flags;
+	void *ret;
+
+	/*
+	 * vmalloc uses GFP_KERNEL for some internal allocations (e.g page tables)
+	 * so the given set of flags has to be compatible.
+	 */
+	WARN_ON_ONCE((flags & GFP_KERNEL) != GFP_KERNEL);
+
+	/*
+	 * Make sure that larger requests are not too disruptive - no OOM
+	 * killer and no allocation failure warnings as we have a fallback
+	 */

mm/util.c unsigned long vm_mmap(struct file *file, unsigned long addr, · line 356

Quoted 4 lines

mm/util.c +4 -0

+	if (size > PAGE_SIZE)
+		kmalloc_flags |= __GFP_NORETRY | __GFP_NOWARN;
+
+	ret = kmalloc_node(size, kmalloc_flags, node);

Along those lines (dealing with larger requests), is there any value in picking some threshold value, and going straight to vmalloc if size is greater than that threshold?

It's less flexible and might even require
occasional maintenance over the years, but it would save some time on *some* systems in some cases...OK, I think I just talked myself out of the whole idea. But I still want to put the question out there, because I think others may also ask it, and I'd like to hear a more experienced opinion.

Quoted 3 lines · John Hubbard

On 01/12/2017 07:37 AM, Michal Hocko wrote:

[...]

Quoted 13 lines

mm/util.c unsigned long vm_mmap(struct file *file, unsigned long addr, · line 328

Quoted 10 lines

mm/util.c +2 -0

index 3cb2164f4099..7e0c240b5760 100644
@@ -324,6 +324,48 @@ unsigned long vm_mmap(struct file *file, unsigned long addr,
 }
 EXPORT_SYMBOL(vm_mmap);
 
+/**
+ * kvmalloc_node - allocate contiguous memory from SLAB with vmalloc fallback

Hi Michal,

Quoted 4 lines

How about this wording instead:

kvmalloc_node - attempt to allocate physically contiguous memory, but upon failure, fall back to non-contiguous (vmalloc) allocation.

OK, why not.

Quoted 9 lines

mm/util.c unsigned long vm_mmap(struct file *file, unsigned long addr, · line 336

Quoted 8 lines

mm/util.c +8 -0

+ * @size: size of the request.
+ * @flags: gfp mask for the allocation - must be compatible (superset) with GFP_KERNEL.
+ * @node: numa node to allocate from
+ *
+ * Uses kmalloc to get the memory but if the allocation fails then falls back
+ * to the vmalloc allocator. Use kvfree for freeing the memory.
+ *
+ * Reclaim modifiers - __GFP_NORETRY, __GFP_REPEAT and __GFP_NOFAIL are not supported

Quoted 6 lines

Is that "Reclaim modifiers" line still true, or is it a leftover from an earlier approach? I am having trouble reconciling it with rest of the patchset, because:

a) the flags argument below is effectively passed on to either kmalloc_node (possibly adding, but not removing flags), or to __vmalloc_node_flags.

The above only says thos are _unsupported_ - in other words the behavior is not defined. Even if flags are passed down to kmalloc resp. vmalloc it doesn't mean they are used that way. Remember that vmalloc uses some hardcoded GFP_KERNEL allocations. So while I could be really strict about this and mask away these flags I doubt this is worth the additional code.

Quoted 3 lines

b) In patch 6/6, you are in fact passing in __GFP_REPEAT to the wrappers (kvzalloc, for example), and again, only adding, not removing flags.

Patch 2 adds a support for __GFP_REPEAT and updates the above line as well.

Quoted 17 lines

Quoted 17 lines

mm/util.c +16 -0

+ */
+void *kvmalloc_node(size_t size, gfp_t flags, int node)
+{
+	gfp_t kmalloc_flags = flags;
+	void *ret;
+
+	/*
+	 * vmalloc uses GFP_KERNEL for some internal allocations (e.g page tables)
+	 * so the given set of flags has to be compatible.
+	 */
+	WARN_ON_ONCE((flags & GFP_KERNEL) != GFP_KERNEL);
+
+	/*
+	 * Make sure that larger requests are not too disruptive - no OOM
+	 * killer and no allocation failure warnings as we have a fallback
+	 */

Quoted 8 lines

mm/util.c unsigned long vm_mmap(struct file *file, unsigned long addr, · line 356

Quoted 4 lines

mm/util.c +4 -0

+	if (size > PAGE_SIZE)
+		kmalloc_flags |= __GFP_NORETRY | __GFP_NOWARN;
+
+	ret = kmalloc_node(size, kmalloc_flags, node);

Along those lines (dealing with larger requests), is there any value in picking some threshold value, and going straight to vmalloc if size is greater than that threshold?

I am not a fan of thresholds. PAGE_ALLOC_COSTLY_ORDER which is internally used by the page allocator has turned out to be a major pain. I do not want to repeat the same mistake again here. Besides that you could hard find a "one suits all" value so it would have to be a part of the API. If we ever grow users who would really like to do something like that then a specialized API should be added.

Quoted 6 lines

It's less flexible and might even require
occasional maintenance over the years, but it would save some time on *some* systems in some cases...OK, I think I just talked myself out of the whole idea. But I still want to put the question out there, because I think others may also ask it, and I'd like to hear a more experienced opinion.

--
Michal Hocko
SUSE Labs

Quoted 1 line · Michal Hocko

On Sun 15-01-17 20:34:13, John Hubbard wrote:

Quoted 7 lines

Quoted 6 lines

Is that "Reclaim modifiers" line still true, or is it a leftover from an earlier approach? I am having trouble reconciling it with rest of the patchset, because:

a) the flags argument below is effectively passed on to either kmalloc_node (possibly adding, but not removing flags), or to __vmalloc_node_flags.

Quoted 6 lines

The above only says thos are _unsupported_ - in other words the behavior is not defined. Even if flags are passed down to kmalloc resp. vmalloc it doesn't mean they are used that way. Remember that vmalloc uses some hardcoded GFP_KERNEL allocations. So while I could be really strict about this and mask away these flags I doubt this is worth the additional code.

I do wonder about passing those flags through to kmalloc. Maybe it is worth stripping out __GFP_NORETRY and __GFP_NOFAIL, after all. It provides some insulation from any future changes to the implementation of kmalloc, and it also makes the documentation more believable.

Quoted 4 lines · John Hubbard

Quoted 1 line · Michal Hocko

On Sun 15-01-17 20:34:13, John Hubbard wrote:

[...]

Quoted 14 lines

Quoted 13 lines

Quoted 6 lines

Is that "Reclaim modifiers" line still true, or is it a leftover from an earlier approach? I am having trouble reconciling it with rest of the patchset, because:

a) the flags argument below is effectively passed on to either kmalloc_node (possibly adding, but not removing flags), or to __vmalloc_node_flags.

The above only says thos are _unsupported_ - in other words the behavior is not defined. Even if flags are passed down to kmalloc resp. vmalloc it doesn't mean they are used that way. Remember that vmalloc uses some hardcoded GFP_KERNEL allocations. So while I could be really strict about this and mask away these flags I doubt this is worth the additional code.

Quoted 4 lines

I do wonder about passing those flags through to kmalloc. Maybe it is worth stripping out __GFP_NORETRY and __GFP_NOFAIL, after all. It provides some insulation from any future changes to the implementation of kmalloc, and it also makes the documentation more believable.

I am not really convinced that we should take an extra steps for these flags. There are no existing users for those flags and new users should follow the documentation.

--
Michal Hocko
SUSE Labs

Quoted 20 lines · Michal Hocko

Quoted 4 lines · John Hubbard

Quoted 1 line · Michal Hocko

On Sun 15-01-17 20:34:13, John Hubbard wrote:

[...]

Quoted 14 lines

Quoted 13 lines

Quoted 6 lines

Is that "Reclaim modifiers" line still true, or is it a leftover from an earlier approach? I am having trouble reconciling it with rest of the patchset, because:

a) the flags argument below is effectively passed on to either kmalloc_node (possibly adding, but not removing flags), or to __vmalloc_node_flags.

The above only says thos are _unsupported_ - in other words the behavior is not defined. Even if flags are passed down to kmalloc resp. vmalloc it doesn't mean they are used that way. Remember that vmalloc uses some hardcoded GFP_KERNEL allocations. So while I could be really strict about this and mask away these flags I doubt this is worth the additional code.

Quoted 8 lines

Quoted 4 lines

I do wonder about passing those flags through to kmalloc. Maybe it is worth stripping out __GFP_NORETRY and __GFP_NOFAIL, after all. It provides some insulation from any future changes to the implementation of kmalloc, and it also makes the documentation more believable.

I am not really convinced that we should take an extra steps for these flags. There are no existing users for those flags and new users should follow the documentation.

OK, let's just fortify the documentation ever so slightly, then, so that users are more likely to do the right thing. How's this sound:

* Reclaim modifiers - __GFP_NORETRY and __GFP_NOFAIL are not supported. (Even
* though the current implementation passes the flags on through to kmalloc and
* vmalloc, that is done for efficiency and to avoid unnecessary code. The caller
* should not pass in these flags.)
*
* __GFP_REPEAT is supported, but only for large (>64kB) allocations.

? Or is that documentation overkill?

Quoted 43 lines · John Hubbard

Quoted 20 lines · Michal Hocko

Quoted 4 lines · John Hubbard

Quoted 1 line · Michal Hocko

On Sun 15-01-17 20:34:13, John Hubbard wrote:

[...]

Quoted 14 lines

Quoted 13 lines

Quoted 6 lines

Is that "Reclaim modifiers" line still true, or is it a leftover from an earlier approach? I am having trouble reconciling it with rest of the patchset, because:

a) the flags argument below is effectively passed on to either kmalloc_node (possibly adding, but not removing flags), or to __vmalloc_node_flags.

The above only says thos are _unsupported_ - in other words the behavior is not defined. Even if flags are passed down to kmalloc resp. vmalloc it doesn't mean they are used that way. Remember that vmalloc uses some hardcoded GFP_KERNEL allocations. So while I could be really strict about this and mask away these flags I doubt this is worth the additional code.

Quoted 8 lines

Quoted 4 lines

I do wonder about passing those flags through to kmalloc. Maybe it is worth stripping out __GFP_NORETRY and __GFP_NOFAIL, after all. It provides some insulation from any future changes to the implementation of kmalloc, and it also makes the documentation more believable.

I am not really convinced that we should take an extra steps for these flags. There are no existing users for those flags and new users should follow the documentation.

OK, let's just fortify the documentation ever so slightly, then, so that users are more likely to do the right thing. How's this sound:

* Reclaim modifiers - __GFP_NORETRY and __GFP_NOFAIL are not supported. (Even
* though the current implementation passes the flags on through to kmalloc and
* vmalloc, that is done for efficiency and to avoid unnecessary code. The caller
* should not pass in these flags.)
*
* __GFP_REPEAT is supported, but only for large (>64kB) allocations.

Quoted 1 line

? Or is that documentation overkill?

Dunno, it sounds like an overkill to me. It is telling more than necessary. If we want to be so vocal about gfp flags then we would have to say much more I suspect. E.g. what about __GFP_HIGHMEM? This flag is supported for vmalloc while unsupported for kmalloc. I am pretty sure there would be other gfp flags to consider and then this would grow borringly large and uninteresting to the point when people simply stop reading it. Let's just be as simple as possible.

--
Michal Hocko
SUSE Labs

Quoted 46 lines · Michal Hocko

Quoted 43 lines · John Hubbard

Quoted 20 lines · Michal Hocko

Quoted 4 lines · John Hubbard

Quoted 1 line · Michal Hocko

On Sun 15-01-17 20:34:13, John Hubbard wrote:

[...]

Quoted 14 lines

Quoted 13 lines

Quoted 6 lines

Is that "Reclaim modifiers" line still true, or is it a leftover from an earlier approach? I am having trouble reconciling it with rest of the patchset, because:

a) the flags argument below is effectively passed on to either kmalloc_node (possibly adding, but not removing flags), or to __vmalloc_node_flags.

The above only says thos are _unsupported_ - in other words the behavior is not defined. Even if flags are passed down to kmalloc resp. vmalloc it doesn't mean they are used that way. Remember that vmalloc uses some hardcoded GFP_KERNEL allocations. So while I could be really strict about this and mask away these flags I doubt this is worth the additional code.

Quoted 8 lines

Quoted 4 lines

I do wonder about passing those flags through to kmalloc. Maybe it is worth stripping out __GFP_NORETRY and __GFP_NOFAIL, after all. It provides some insulation from any future changes to the implementation of kmalloc, and it also makes the documentation more believable.

I am not really convinced that we should take an extra steps for these flags. There are no existing users for those flags and new users should follow the documentation.

OK, let's just fortify the documentation ever so slightly, then, so that users are more likely to do the right thing. How's this sound:

* Reclaim modifiers - __GFP_NORETRY and __GFP_NOFAIL are not supported. (Even
* though the current implementation passes the flags on through to kmalloc and
* vmalloc, that is done for efficiency and to avoid unnecessary code. The caller
* should not pass in these flags.)
*
* __GFP_REPEAT is supported, but only for large (>64kB) allocations.

Quoted 1 line

? Or is that documentation overkill?

Quoted 7 lines

Dunno, it sounds like an overkill to me. It is telling more than necessary. If we want to be so vocal about gfp flags then we would have to say much more I suspect. E.g. what about __GFP_HIGHMEM? This flag is supported for vmalloc while unsupported for kmalloc. I am pretty sure there would be other gfp flags to consider and then this would grow borringly large and uninteresting to the point when people simply stop reading it. Let's just be as simple as possible.

Agreed, on the simplicity point: simple and clear is ideal. But here, it's merely short, and not quite simple. :) People will look at that short bit of documentation, and then notice that the flags are, in fact, all passed right on through down to both kmalloc_node and __vmalloc_node_flags.

If you don't want too much documentation, then I'd be inclined to say something higher-level, about the intent, rather than mentioning those two flags directly. Because as it stands, the documentation contradicts what the code does.

Quoted 62 lines · John Hubbard

Quoted 46 lines · Michal Hocko

Quoted 43 lines · John Hubbard

Quoted 20 lines · Michal Hocko

Quoted 4 lines · John Hubbard

Quoted 1 line · Michal Hocko

On Sun 15-01-17 20:34:13, John Hubbard wrote:

[...]

Quoted 14 lines

Quoted 13 lines

Quoted 6 lines

Is that "Reclaim modifiers" line still true, or is it a leftover from an earlier approach? I am having trouble reconciling it with rest of the patchset, because:

a) the flags argument below is effectively passed on to either kmalloc_node (possibly adding, but not removing flags), or to __vmalloc_node_flags.

The above only says thos are _unsupported_ - in other words the behavior is not defined. Even if flags are passed down to kmalloc resp. vmalloc it doesn't mean they are used that way. Remember that vmalloc uses some hardcoded GFP_KERNEL allocations. So while I could be really strict about this and mask away these flags I doubt this is worth the additional code.

Quoted 8 lines

Quoted 4 lines

I do wonder about passing those flags through to kmalloc. Maybe it is worth stripping out __GFP_NORETRY and __GFP_NOFAIL, after all. It provides some insulation from any future changes to the implementation of kmalloc, and it also makes the documentation more believable.

I am not really convinced that we should take an extra steps for these flags. There are no existing users for those flags and new users should follow the documentation.

OK, let's just fortify the documentation ever so slightly, then, so that users are more likely to do the right thing. How's this sound:

* Reclaim modifiers - __GFP_NORETRY and __GFP_NOFAIL are not supported. (Even
* though the current implementation passes the flags on through to kmalloc and
* vmalloc, that is done for efficiency and to avoid unnecessary code. The caller
* should not pass in these flags.)
*
* __GFP_REPEAT is supported, but only for large (>64kB) allocations.

Quoted 1 line

? Or is that documentation overkill?

Quoted 7 lines

Dunno, it sounds like an overkill to me. It is telling more than necessary. If we want to be so vocal about gfp flags then we would have to say much more I suspect. E.g. what about __GFP_HIGHMEM? This flag is supported for vmalloc while unsupported for kmalloc. I am pretty sure there would be other gfp flags to consider and then this would grow borringly large and uninteresting to the point when people simply stop reading it. Let's just be as simple as possible.

Agreed, on the simplicity point: simple and clear is ideal. But here, it's merely short, and not quite simple. :) People will look at that short bit of documentation, and then notice that the flags are, in fact, all passed right on through down to both kmalloc_node and __vmalloc_node_flags.

Quoted 4 lines

If you don't want too much documentation, then I'd be inclined to say something higher-level, about the intent, rather than mentioning those two flags directly. Because as it stands, the documentation contradicts what the code does.

Feel free to suggest a better wording. I am, of course, open to any changes.

--
Michal Hocko
SUSE Labs

Quoted 63 lines · Michal Hocko

Quoted 62 lines · John Hubbard

Quoted 46 lines · Michal Hocko

Quoted 43 lines · John Hubbard

Quoted 20 lines · Michal Hocko

Quoted 4 lines · John Hubbard

Quoted 1 line · Michal Hocko

On Sun 15-01-17 20:34:13, John Hubbard wrote:

[...]

Quoted 14 lines

Quoted 13 lines

Quoted 6 lines

Is that "Reclaim modifiers" line still true, or is it a leftover from an earlier approach? I am having trouble reconciling it with rest of the patchset, because:

a) the flags argument below is effectively passed on to either kmalloc_node (possibly adding, but not removing flags), or to __vmalloc_node_flags.

The above only says thos are _unsupported_ - in other words the behavior is not defined. Even if flags are passed down to kmalloc resp. vmalloc it doesn't mean they are used that way. Remember that vmalloc uses some hardcoded GFP_KERNEL allocations. So while I could be really strict about this and mask away these flags I doubt this is worth the additional code.

Quoted 8 lines

Quoted 4 lines

I do wonder about passing those flags through to kmalloc. Maybe it is worth stripping out __GFP_NORETRY and __GFP_NOFAIL, after all. It provides some insulation from any future changes to the implementation of kmalloc, and it also makes the documentation more believable.

I am not really convinced that we should take an extra steps for these flags. There are no existing users for those flags and new users should follow the documentation.

OK, let's just fortify the documentation ever so slightly, then, so that users are more likely to do the right thing. How's this sound:

* Reclaim modifiers - __GFP_NORETRY and __GFP_NOFAIL are not supported. (Even
* though the current implementation passes the flags on through to kmalloc and
* vmalloc, that is done for efficiency and to avoid unnecessary code. The caller
* should not pass in these flags.)
*
* __GFP_REPEAT is supported, but only for large (>64kB) allocations.

Quoted 1 line

? Or is that documentation overkill?

Quoted 7 lines

Dunno, it sounds like an overkill to me. It is telling more than necessary. If we want to be so vocal about gfp flags then we would have to say much more I suspect. E.g. what about __GFP_HIGHMEM? This flag is supported for vmalloc while unsupported for kmalloc. I am pretty sure there would be other gfp flags to consider and then this would grow borringly large and uninteresting to the point when people simply stop reading it. Let's just be as simple as possible.

Agreed, on the simplicity point: simple and clear is ideal. But here, it's merely short, and not quite simple. :) People will look at that short bit of documentation, and then notice that the flags are, in fact, all passed right on through down to both kmalloc_node and __vmalloc_node_flags.

Quoted 7 lines

Quoted 4 lines

If you don't want too much documentation, then I'd be inclined to say something higher-level, about the intent, rather than mentioning those two flags directly. Because as it stands, the documentation contradicts what the code does.

Feel free to suggest a better wording. I am, of course, open to any changes.

OK, here's the best I've got, I tried to keep it concise, but (as you suspected) I'm not sure it's actually any better than the original:

* Reclaim modifiers - __GFP_NORETRY and __GFP_NOFAIL should not be passed in.
* Passing in __GFP_REPEAT is supported, but note that it is ignored for small
* (<=64KB) allocations, during the kmalloc attempt.

__GFP_REPEAT is fully
* honored for all allocation sizes during the second part: the vmalloc attempt.

Quoted 79 lines · John Hubbard

Quoted 63 lines · Michal Hocko

Quoted 62 lines · John Hubbard

Quoted 46 lines · Michal Hocko

Quoted 43 lines · John Hubbard

Quoted 20 lines · Michal Hocko

Quoted 4 lines · John Hubbard

Quoted 1 line · Michal Hocko

On Sun 15-01-17 20:34:13, John Hubbard wrote:

[...]

Quoted 14 lines

Quoted 13 lines

Quoted 6 lines

Is that "Reclaim modifiers" line still true, or is it a leftover from an earlier approach? I am having trouble reconciling it with rest of the patchset, because:

a) the flags argument below is effectively passed on to either kmalloc_node (possibly adding, but not removing flags), or to __vmalloc_node_flags.

The above only says thos are _unsupported_ - in other words the behavior is not defined. Even if flags are passed down to kmalloc resp. vmalloc it doesn't mean they are used that way. Remember that vmalloc uses some hardcoded GFP_KERNEL allocations. So while I could be really strict about this and mask away these flags I doubt this is worth the additional code.

Quoted 8 lines

Quoted 4 lines

I do wonder about passing those flags through to kmalloc. Maybe it is worth stripping out __GFP_NORETRY and __GFP_NOFAIL, after all. It provides some insulation from any future changes to the implementation of kmalloc, and it also makes the documentation more believable.

I am not really convinced that we should take an extra steps for these flags. There are no existing users for those flags and new users should follow the documentation.

OK, let's just fortify the documentation ever so slightly, then, so that users are more likely to do the right thing. How's this sound:

* Reclaim modifiers - __GFP_NORETRY and __GFP_NOFAIL are not supported. (Even
* though the current implementation passes the flags on through to kmalloc and
* vmalloc, that is done for efficiency and to avoid unnecessary code. The caller
* should not pass in these flags.)
*
* __GFP_REPEAT is supported, but only for large (>64kB) allocations.

Quoted 1 line

? Or is that documentation overkill?

Quoted 7 lines

Dunno, it sounds like an overkill to me. It is telling more than necessary. If we want to be so vocal about gfp flags then we would have to say much more I suspect. E.g. what about __GFP_HIGHMEM? This flag is supported for vmalloc while unsupported for kmalloc. I am pretty sure there would be other gfp flags to consider and then this would grow borringly large and uninteresting to the point when people simply stop reading it. Let's just be as simple as possible.

Agreed, on the simplicity point: simple and clear is ideal. But here, it's merely short, and not quite simple. :) People will look at that short bit of documentation, and then notice that the flags are, in fact, all passed right on through down to both kmalloc_node and __vmalloc_node_flags.

Quoted 7 lines

Quoted 4 lines

If you don't want too much documentation, then I'd be inclined to say something higher-level, about the intent, rather than mentioning those two flags directly. Because as it stands, the documentation contradicts what the code does.

Feel free to suggest a better wording. I am, of course, open to any changes.

OK, here's the best I've got, I tried to keep it concise, but (as you suspected) I'm not sure it's actually any better than the original:

* Reclaim modifiers - __GFP_NORETRY and __GFP_NOFAIL should not be passed in.
* Passing in __GFP_REPEAT is supported, but note that it is ignored for small
* (<=64KB) allocations, during the kmalloc attempt.

Quoted 2 lines

__GFP_REPEAT is fully
* honored for all allocation sizes during the second part: the vmalloc attempt.

this is not true to be really precise because vmalloc doesn't respect the given gfp mask all the way down (look at the pte initialization).

Quoted 1 line · Michal Hocko

On Tue 17-01-17 21:59:13, John Hubbard wrote:

Quoted 10 lines

Quoted 6 lines

* Reclaim modifiers - __GFP_NORETRY and __GFP_NOFAIL should not be passed in.
* Passing in __GFP_REPEAT is supported, but note that it is ignored for small
* (<=64KB) allocations, during the kmalloc attempt.

__GFP_REPEAT is fully
* honored for all allocation sizes during the second part: the vmalloc attempt.

this is not true to be really precise because vmalloc doesn't respect the given gfp mask all the way down (look at the pte initialization).

I'm having some difficulty in locating that pte initialization part, am I on the wrong code path? Here's what I checked, before making the claim about __GFP_REPEAT being honored:

kvmalloc_node
__vmalloc_node_flags
__vmalloc_node
__vmalloc_node_range
__vmalloc_area_node

alloc_pages_node

__alloc_pages_node
__alloc_pages
__alloc_pages_nodemask
__alloc_pages_slowpath

...and __alloc_pages_slowpath does the __GFP_REPEAT handling:

    /*
     * Do not retry costly high order allocations unless they are
     * __GFP_REPEAT
     */
    if (order > PAGE_ALLOC_COSTLY_ORDER && !(gfp_mask & __GFP_REPEAT))
        goto nopage;

Quoted 4 lines · John Hubbard

Quoted 1 line · Michal Hocko

On Tue 17-01-17 21:59:13, John Hubbard wrote:

[...]

Quoted 15 lines

Quoted 10 lines

Quoted 6 lines

* Reclaim modifiers - __GFP_NORETRY and __GFP_NOFAIL should not be passed in.
* Passing in __GFP_REPEAT is supported, but note that it is ignored for small
* (<=64KB) allocations, during the kmalloc attempt.

__GFP_REPEAT is fully
* honored for all allocation sizes during the second part: the vmalloc attempt.

this is not true to be really precise because vmalloc doesn't respect the given gfp mask all the way down (look at the pte initialization).

I'm having some difficulty in locating that pte initialization part, am I on the wrong code path? Here's what I checked, before making the claim about __GFP_REPEAT being honored:

Quoted 5 lines

kvmalloc_node
__vmalloc_node_flags
__vmalloc_node
__vmalloc_node_range
__vmalloc_area_node

	    map_vm_area
	      vmap_page_range
	        vmap_page_range_noflush
		  vmap_pud_range
		    pud_alloc
		      __pud_alloc
		        pud_alloc_one

pud will be allocated but the same pattern repeats on the pmd and pte levels. This is btw. one of the reasons why vmalloc with gfp flags is tricky!

moreover

Quoted 1 line

alloc_pages_node

this is order-0 request so...

Quoted 8 lines

__alloc_pages_node
__alloc_pages
__alloc_pages_nodemask
__alloc_pages_slowpath

...and __alloc_pages_slowpath does the __GFP_REPEAT handling:

Quoted 6 lines

    /*
     * Do not retry costly high order allocations unless they are
     * __GFP_REPEAT
     */
    if (order > PAGE_ALLOC_COSTLY_ORDER && !(gfp_mask & __GFP_REPEAT))
        goto nopage;

... this doesn't apply

So that leaves us with maybe this for documentation?

* Reclaim modifiers - __GFP_NORETRY and __GFP_NOFAIL should not be passed in.
* Passing in __GFP_REPEAT is supported, and will cause the following behavior:
* for larger (>64KB) allocations, the first part (kmalloc) will do some
* retrying, before falling back to vmalloc.

On Thu 19-01-17 01:09:35, John Hubbard wrote:
[...]

Quoted 6 lines

So that leaves us with maybe this for documentation?

* Reclaim modifiers - __GFP_NORETRY and __GFP_NOFAIL should not be passed in.
* Passing in __GFP_REPEAT is supported, and will cause the following behavior:
* for larger (>64KB) allocations, the first part (kmalloc) will do some
* retrying, before falling back to vmalloc.

I am worried this is just too vague. It doesn't really help user to decide whether "do some retrying" is what he really want's or needs.

So I would rather see the following.
"
* Reclaim modifiers - __GFP_NORETRY and __GFP_NOFAIL are not supported. __GFP_REPEAT
* is supported only for large (>32kB) allocations and it should be used when using
* kmalloc is preferable because vmalloc fallback has visible performance drawbacks.
"

I would also add
"
Any use of gfp flags outside of GFP_KERNEL should be consulted with mm people. "

Does it sound any better?

--
Michal Hocko
SUSE Labs

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

(quoted diff) +20 -0

+void *kvmalloc_node(size_t size, gfp_t flags, int node)
+{
+	gfp_t kmalloc_flags = flags;
+	void *ret;
+
+	/*
+	 * vmalloc uses GFP_KERNEL for some internal allocations (e.g page tables)
+	 * so the given set of flags has to be compatible.
+	 */
+	WARN_ON_ONCE((flags & GFP_KERNEL) != GFP_KERNEL);
+
+	/*
+	 * Make sure that larger requests are not too disruptive - no OOM
+	 * killer and no allocation failure warnings as we have a fallback
+	 */
+	if (size > PAGE_SIZE)
+		kmalloc_flags |= __GFP_NORETRY | __GFP_NOWARN;
+
+	ret = kmalloc_node(size, kmalloc_flags, node);
+

On Thu 12-01-17 16:37:12, Michal Hocko wrote:
[...]

Quoted 20 lines

(quoted diff) +20 -0

+void *kvmalloc_node(size_t size, gfp_t flags, int node)
+{
+	gfp_t kmalloc_flags = flags;
+	void *ret;
+
+	/*
+	 * vmalloc uses GFP_KERNEL for some internal allocations (e.g page tables)
+	 * so the given set of flags has to be compatible.
+	 */
+	WARN_ON_ONCE((flags & GFP_KERNEL) != GFP_KERNEL);
+
+	/*
+	 * Make sure that larger requests are not too disruptive - no OOM
+	 * killer and no allocation failure warnings as we have a fallback
+	 */
+	if (size > PAGE_SIZE)
+		kmalloc_flags |= __GFP_NORETRY | __GFP_NOWARN;
+
+	ret = kmalloc_node(size, kmalloc_flags, node);
+

Review

Quoted 10 lines

(quoted diff) +10 -0

+	/*
+	 * It doesn't really make sense to fallback to vmalloc for sub page
+	 * requests
+	 */
+	if (ret || size <= PAGE_SIZE)
+		return ret;
+
+	return __vmalloc_node_flags(size, node, flags);
+}
+EXPORT_SYMBOL(kvmalloc_node);

While discussing bpf change I've realized that the vmalloc fallback doesn't request __GFP_HIGHMEM. So I've updated the patch to do so. All the current users except for f2fs_kv[zm]alloc which just seemed to forgot or didn't know about the flag. In the next step, I would like to check whether we actually have any __vmalloc* user which would strictly refuse __GFP_HIGHMEM because I do not really see any reason for that and if there is none then I would simply pull __GFP_HIGHMEM handling into the vmalloc.

So before I resend the full series again, can I keep acks with the following?

From: Michal Hocko <[email protected]>

vhost code uses __GFP_REPEAT when allocating vhost_virtqueue resp. vhost_vsock because it would really like to prefer kmalloc to the vmalloc fallback - see 23cc5a991c7a ("vhost-net: extend device allocation to vmalloc") for more context. Michael Tsirkin has also noted:
"
__GFP_REPEAT overhead is during allocation time. Using vmalloc means all accesses are slowed down. Allocation is not on data path, accesses are. "

The similar applies to other vhost_kvzalloc users.

Let's teach kvmalloc_node to handle __GFP_REPEAT properly. There are two things to be careful about. First we should prevent from the OOM killer and so have to involve __GFP_NORETRY by default and secondly override __GFP_REPEAT for !costly order requests as the __GFP_REPEAT is ignored for !costly orders.

Supporting __GFP_REPEAT like semantic for !costly request is possible it would require changes in the page allocator. This is out of scope of this patch.

This patch shouldn't introduce any functional change.

Cc "Michael S. Tsirkin" <[email protected]>

Acked-by Vlastimil Babka <[email protected]>

Signed-off-by Michal Hocko <[email protected]>

---
 drivers/vhost/net.c   |  9 +++------
 drivers/vhost/vhost.c | 15 +++------------
 drivers/vhost/vsock.c |  9 +++------
 mm/util.c             | 17 ++++++++++++++---
 4 files changed, 23 insertions(+), 27 deletions(-)

drivers/vhost/net.c +3 -6

index 5dc34653274a..105cd04c7414 100644
@@ -797,12 +797,9 @@ static int vhost_net_open(struct inode *inode, struct file *f)
 	struct vhost_virtqueue **vqs;
 	int i;
 
-	n = kmalloc(sizeof *n, GFP_KERNEL | __GFP_NOWARN | __GFP_REPEAT);
-	if (!n) {
-		n = vmalloc(sizeof *n);
-		if (!n)
-			return -ENOMEM;
-	}
+	n = kvmalloc(sizeof *n, GFP_KERNEL | __GFP_REPEAT);
+	if (!n)
+		return -ENOMEM;
 	vqs = kmalloc(VHOST_NET_VQ_MAX * sizeof(*vqs), GFP_KERNEL);
 	if (!vqs) {
 		kvfree(n);

drivers/vhost/vhost.c +3 -12

index d6432603880c..d2bf8a41f55e 100644
@@ -515,18 +515,9 @@ long vhost_dev_set_owner(struct vhost_dev *dev)
 }
 EXPORT_SYMBOL_GPL(vhost_dev_set_owner);
 
-static void *vhost_kvzalloc(unsigned long size)
-{
-	void *n = kzalloc(size, GFP_KERNEL | __GFP_NOWARN | __GFP_REPEAT);
-
-	if (!n)
-		n = vzalloc(size);
-	return n;
-}
-
 struct vhost_umem *vhost_dev_reset_owner_prepare(void)
 {
-	return vhost_kvzalloc(sizeof(struct vhost_umem));
+	return kvzalloc(sizeof(struct vhost_umem), GFP_KERNEL);
 }
 EXPORT_SYMBOL_GPL(vhost_dev_reset_owner_prepare);
 

@@ -1190,7 +1181,7 @@ EXPORT_SYMBOL_GPL(vhost_vq_access_ok);
 
 static struct vhost_umem *vhost_umem_alloc(void)
 {
-	struct vhost_umem *umem = vhost_kvzalloc(sizeof(*umem));
+	struct vhost_umem *umem = kvzalloc(sizeof(*umem), GFP_KERNEL);
 
 	if (!umem)
 		return NULL;

@@ -1216,7 +1207,7 @@ static long vhost_set_memory(struct vhost_dev *d, struct vhost_memory __user *m)
 		return -EOPNOTSUPP;
 	if (mem.nregions > max_mem_regions)
 		return -E2BIG;
-	newmem = vhost_kvzalloc(size + mem.nregions * sizeof(*m->regions));
+	newmem = kvzalloc(size + mem.nregions * sizeof(*m->regions), GFP_KERNEL);
 	if (!newmem)
 		return -ENOMEM;
 

drivers/vhost/vsock.c +3 -6

index bbbf588540ed..7e0159867553 100644
@@ -455,12 +455,9 @@ static int vhost_vsock_dev_open(struct inode *inode, struct file *file)
 	/* This struct is large and allocation could fail, fall back to vmalloc
 	 * if there is no other way.
 	 */
-	vsock = kzalloc(sizeof(*vsock), GFP_KERNEL | __GFP_NOWARN | __GFP_REPEAT);
-	if (!vsock) {
-		vsock = vmalloc(sizeof(*vsock));
-		if (!vsock)
-			return -ENOMEM;
-	}
+	vsock = kvmalloc(sizeof(*vsock), GFP_KERNEL | __GFP_REPEAT);
+	if (!vsock)
+		return -ENOMEM;
 
 	vqs = kmalloc_array(ARRAY_SIZE(vsock->vqs), sizeof(*vqs), GFP_KERNEL);
 	if (!vqs) {

mm/util.c +14 -3

index 7e0c240b5760..9306244b9f41 100644
@@ -333,7 +333,8 @@ EXPORT_SYMBOL(vm_mmap);
  * Uses kmalloc to get the memory but if the allocation fails then falls back
  * to the vmalloc allocator. Use kvfree for freeing the memory.
  *
- * Reclaim modifiers - __GFP_NORETRY, __GFP_REPEAT and __GFP_NOFAIL are not supported
+ * Reclaim modifiers - __GFP_NORETRY and __GFP_NOFAIL are not supported. __GFP_REPEAT
+ * is supported only for large (>64kB) allocations
  */
 void *kvmalloc_node(size_t size, gfp_t flags, int node)
 {

@@ -350,8 +351,18 @@ void *kvmalloc_node(size_t size, gfp_t flags, int node)
 	 * Make sure that larger requests are not too disruptive - no OOM
 	 * killer and no allocation failure warnings as we have a fallback
 	 */
-	if (size > PAGE_SIZE)
-		kmalloc_flags |= __GFP_NORETRY | __GFP_NOWARN;
+	if (size > PAGE_SIZE) {
+		kmalloc_flags |= __GFP_NOWARN;
+
+		/*
+		 * We have to override __GFP_REPEAT by __GFP_NORETRY for !costly
+		 * requests because there is no other way to tell the allocator
+		 * that we want to fail rather than retry endlessly.
+		 */
+		if (!(kmalloc_flags & __GFP_REPEAT) ||
+				(size <= PAGE_SIZE << PAGE_ALLOC_COSTLY_ORDER))
+			kmalloc_flags |= __GFP_NORETRY;
+	}
 
 	ret = kmalloc_node(size, kmalloc_flags, node);
 

Signature · 1 line

2.11.0

drivers/vhost/net.c +0 -0

index 5dc34653274a..105cd04c7414 100644

mm/util.c +5 -2

  */
 void *kvmalloc_node(size_t size, gfp_t flags, int node)
 {

@@ -350,8 +351,18 @@ void *kvmalloc_node(size_t size, gfp_t flags, int node)
 	 * Make sure that larger requests are not too disruptive - no OOM
 	 * killer and no allocation failure warnings as we have a fallback
 	 */
-	if (size > PAGE_SIZE)
-		kmalloc_flags |= __GFP_NORETRY | __GFP_NOWARN;
+	if (size > PAGE_SIZE) {
+		kmalloc_flags |= __GFP_NOWARN;
+
+		/*
+		 * We have to override __GFP_REPEAT by __GFP_NORETRY for !costly

On 2017/01/13 0:37, Michal Hocko wrote:

Quoted 5 lines

mm/util.c +0 -0

index 7e0c240b5760..9306244b9f41 100644
@@ -333,7 +333,8 @@ EXPORT_SYMBOL(vm_mmap);

mm/util.c EXPORT_SYMBOL(vm_mmap); · line 337

Quoted 6 lines

mm/util.c +2 -1

  * Uses kmalloc to get the memory but if the allocation fails then falls back
  * to the vmalloc allocator. Use kvfree for freeing the memory.
  *
- * Reclaim modifiers - __GFP_NORETRY, __GFP_REPEAT and __GFP_NOFAIL are not supported
+ * Reclaim modifiers - __GFP_NORETRY and __GFP_NOFAIL are not supported. __GFP_REPEAT
+ * is supported only for large (>64kB) allocations

Isn't this ">32kB" (i.e. __GFP_REPEAT is supported for 64kB allocation) ?

From: Michal Hocko <[email protected]>

vhost code uses __GFP_REPEAT when allocating vhost_virtqueue resp. vhost_vsock because it would really like to prefer kmalloc to the vmalloc fallback - see 23cc5a991c7a ("vhost-net: extend device allocation to vmalloc") for more context. Michael Tsirkin has also noted:
"
__GFP_REPEAT overhead is during allocation time. Using vmalloc means all accesses are slowed down. Allocation is not on data path, accesses are. "

The similar applies to other vhost_kvzalloc users.

Let's teach kvmalloc_node to handle __GFP_REPEAT properly. There are two things to be careful about. First we should prevent from the OOM killer and so have to involve __GFP_NORETRY by default and secondly override __GFP_REPEAT for !costly order requests as the __GFP_REPEAT is ignored for !costly orders.

Supporting __GFP_REPEAT like semantic for !costly request is possible it would require changes in the page allocator. This is out of scope of this patch.

This patch shouldn't introduce any functional change.

Cc "Michael S. Tsirkin" <[email protected]>

Acked-by Vlastimil Babka <[email protected]>

Signed-off-by Michal Hocko <[email protected]>

---
 drivers/vhost/net.c   |  9 +++------
 drivers/vhost/vhost.c | 15 +++------------
 drivers/vhost/vsock.c |  9 +++------
 mm/util.c             | 17 ++++++++++++++---
 4 files changed, 23 insertions(+), 27 deletions(-)

drivers/vhost/net.c +3 -6

index 5dc34653274a..105cd04c7414 100644
@@ -797,12 +797,9 @@ static int vhost_net_open(struct inode *inode, struct file *f)
 	struct vhost_virtqueue **vqs;
 	int i;
 
-	n = kmalloc(sizeof *n, GFP_KERNEL | __GFP_NOWARN | __GFP_REPEAT);
-	if (!n) {
-		n = vmalloc(sizeof *n);
-		if (!n)
-			return -ENOMEM;
-	}
+	n = kvmalloc(sizeof *n, GFP_KERNEL | __GFP_REPEAT);
+	if (!n)
+		return -ENOMEM;
 	vqs = kmalloc(VHOST_NET_VQ_MAX * sizeof(*vqs), GFP_KERNEL);
 	if (!vqs) {
 		kvfree(n);

drivers/vhost/vhost.c +3 -12

index d6432603880c..d2bf8a41f55e 100644
@@ -515,18 +515,9 @@ long vhost_dev_set_owner(struct vhost_dev *dev)
 }
 EXPORT_SYMBOL_GPL(vhost_dev_set_owner);
 
-static void *vhost_kvzalloc(unsigned long size)
-{
-	void *n = kzalloc(size, GFP_KERNEL | __GFP_NOWARN | __GFP_REPEAT);
-
-	if (!n)
-		n = vzalloc(size);
-	return n;
-}
-
 struct vhost_umem *vhost_dev_reset_owner_prepare(void)
 {
-	return vhost_kvzalloc(sizeof(struct vhost_umem));
+	return kvzalloc(sizeof(struct vhost_umem), GFP_KERNEL);
 }
 EXPORT_SYMBOL_GPL(vhost_dev_reset_owner_prepare);
 

@@ -1190,7 +1181,7 @@ EXPORT_SYMBOL_GPL(vhost_vq_access_ok);
 
 static struct vhost_umem *vhost_umem_alloc(void)
 {
-	struct vhost_umem *umem = vhost_kvzalloc(sizeof(*umem));
+	struct vhost_umem *umem = kvzalloc(sizeof(*umem), GFP_KERNEL);
 
 	if (!umem)
 		return NULL;

@@ -1216,7 +1207,7 @@ static long vhost_set_memory(struct vhost_dev *d, struct vhost_memory __user *m)
 		return -EOPNOTSUPP;
 	if (mem.nregions > max_mem_regions)
 		return -E2BIG;
-	newmem = vhost_kvzalloc(size + mem.nregions * sizeof(*m->regions));
+	newmem = kvzalloc(size + mem.nregions * sizeof(*m->regions), GFP_KERNEL);
 	if (!newmem)
 		return -ENOMEM;
 

drivers/vhost/vsock.c +3 -6

index bbbf588540ed..7e0159867553 100644
@@ -455,12 +455,9 @@ static int vhost_vsock_dev_open(struct inode *inode, struct file *file)
 	/* This struct is large and allocation could fail, fall back to vmalloc
 	 * if there is no other way.
 	 */
-	vsock = kzalloc(sizeof(*vsock), GFP_KERNEL | __GFP_NOWARN | __GFP_REPEAT);
-	if (!vsock) {
-		vsock = vmalloc(sizeof(*vsock));
-		if (!vsock)
-			return -ENOMEM;
-	}
+	vsock = kvmalloc(sizeof(*vsock), GFP_KERNEL | __GFP_REPEAT);
+	if (!vsock)
+		return -ENOMEM;
 
 	vqs = kmalloc_array(ARRAY_SIZE(vsock->vqs), sizeof(*vqs), GFP_KERNEL);
 	if (!vqs) {

mm/util.c +14 -3

index 7e0c240b5760..9306244b9f41 100644
@@ -333,7 +333,8 @@ EXPORT_SYMBOL(vm_mmap);
  * Uses kmalloc to get the memory but if the allocation fails then falls back
  * to the vmalloc allocator. Use kvfree for freeing the memory.
  *
- * Reclaim modifiers - __GFP_NORETRY, __GFP_REPEAT and __GFP_NOFAIL are not supported
+ * Reclaim modifiers - __GFP_NORETRY and __GFP_NOFAIL are not supported. __GFP_REPEAT
+ * is supported only for large (>64kB) allocations
  */
 void *kvmalloc_node(size_t size, gfp_t flags, int node)
 {

@@ -350,8 +351,18 @@ void *kvmalloc_node(size_t size, gfp_t flags, int node)
 	 * Make sure that larger requests are not too disruptive - no OOM
 	 * killer and no allocation failure warnings as we have a fallback
 	 */
-	if (size > PAGE_SIZE)
-		kmalloc_flags |= __GFP_NORETRY | __GFP_NOWARN;
+	if (size > PAGE_SIZE) {
+		kmalloc_flags |= __GFP_NOWARN;
+
+		/*
+		 * We have to override __GFP_REPEAT by __GFP_NORETRY for !costly
+		 * requests because there is no other way to tell the allocator
+		 * that we want to fail rather than retry endlessly.
+		 */
+		if (!(kmalloc_flags & __GFP_REPEAT) ||
+				(size <= PAGE_SIZE << PAGE_ALLOC_COSTLY_ORDER))
+			kmalloc_flags |= __GFP_NORETRY;
+	}
 
 	ret = kmalloc_node(size, kmalloc_flags, node);
 

Signature · 1 line

2.11.0

From: Michal Hocko <[email protected]>

There are many code paths opencoding kvmalloc. Let's use the helper instead. The main difference to kvmalloc is that those users are usually not considering all the aspects of the memory allocator. E.g. allocation requests < 64kB are basically never failing and invoke OOM killer to satisfy the allocation. This sounds too disruptive for something that has a reasonable fallback - the vmalloc. On the other hand those requests might fallback to vmalloc even when the memory allocator would succeed after several more reclaim/compaction attempts previously. There is no guarantee something like that happens though.

This patch converts many of those places to kv[mz]alloc* helpers because they are more conservative.

arch/s390/kvm/kvm-s390.c +1 -4

index 4f74511015b8..e6bbb33d2956 100644
@@ -1126,10 +1126,7 @@ static long kvm_s390_get_skeys(struct kvm *kvm, struct kvm_s390_skeys *args)
 	if (args->count < 1 || args->count > KVM_S390_SKEYS_MAX)
 		return -EINVAL;
 
-	keys = kmalloc_array(args->count, sizeof(uint8_t),
-			     GFP_KERNEL | __GFP_NOWARN);
-	if (!keys)
-		keys = vmalloc(sizeof(uint8_t) * args->count);
+	keys = kvmalloc(args->count * sizeof(uint8_t), GFP_KERNEL);
 	if (!keys)
 		return -ENOMEM;