search for: __gfp_repeat

As vhost scsi device struct is large, if the device is created on a busy system, kzalloc() might fail, so this patch does a fallback to vzalloc(). As vmalloc() adds overhead on data-path, add __GFP_REPEAT to kzalloc() flags to do this fallback only when really needed. Reported-by: Dan Aloni <alonid at stratoscale.com> Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- I put this on my vhost fixes branch, intend to merge for 3.12. Dan, could you please confirm this works for you?...

As vhost scsi device struct is large, if the device is created on a busy system, kzalloc() might fail, so this patch does a fallback to vzalloc(). As vmalloc() adds overhead on data-path, add __GFP_REPEAT to kzalloc() flags to do this fallback only when really needed. Reported-by: Dan Aloni <alonid at stratoscale.com> Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- I put this on my vhost fixes branch, intend to merge for 3.12. Dan, could you please confirm this works for you?...

...+++ b/drivers/block/xen-blkfront.c @@ -1203,11 +1203,10 @@ static int blkif_recover(struct blkfront_info *info) int j; /* Stage 1: Make a safe copy of the shadow state. */ - copy = kmalloc(sizeof(info->shadow), + copy = kmemdup(info->shadow, sizeof(info->shadow), GFP_NOIO | __GFP_REPEAT | __GFP_HIGH); if (!copy) return -ENOMEM; - memcpy(copy, info->shadow, sizeof(info->shadow)); /* Stage 2: Set up free list. */ memset(&info->shadow, 0, sizeof(info->shadow)); -- 1.7.10.4

...+++ b/drivers/block/xen-blkfront.c @@ -1203,11 +1203,10 @@ static int blkif_recover(struct blkfront_info *info) int j; /* Stage 1: Make a safe copy of the shadow state. */ - copy = kmalloc(sizeof(info->shadow), + copy = kmemdup(info->shadow, sizeof(info->shadow), GFP_NOIO | __GFP_REPEAT | __GFP_HIGH); if (!copy) return -ENOMEM; - memcpy(copy, info->shadow, sizeof(info->shadow)); /* Stage 2: Set up free list. */ memset(&info->shadow, 0, sizeof(info->shadow)); -- 1.7.10.4

...until I've encountered vhost_vsock_dev_open resp. vhost_vsock_dev_open which are trying to use GFP_REPEAT for kmalloc. 23cc5a991c7a ("vhost-net: extend device allocation to vmalloc") explains the motivation as follows: " As vmalloc() adds overhead on a critical network path, add __GFP_REPEAT to kzalloc() flags to do this fallback only when really needed. " I am wondering whether vmalloc adds more overhead than GFP_REPEAT which can get pretty costly for order-4 allocation which will be used here as struct vhost_net seems to be 36104 (at least in with my config). Have you ever meas...

...until I've encountered vhost_vsock_dev_open resp. vhost_vsock_dev_open which are trying to use GFP_REPEAT for kmalloc. 23cc5a991c7a ("vhost-net: extend device allocation to vmalloc") explains the motivation as follows: " As vmalloc() adds overhead on a critical network path, add __GFP_REPEAT to kzalloc() flags to do this fallback only when really needed. " I am wondering whether vmalloc adds more overhead than GFP_REPEAT which can get pretty costly for order-4 allocation which will be used here as struct vhost_net seems to be 36104 (at least in with my config). Have you ever meas...

...e.com> > > This extra indirection is likely to have measureable cost though. > > net core saw a similar problem, it was fixed in patch > net: allow large number of tx queues > > So let's do it in a similar way: try to allocate with > GFP_KERNEL | __GFP_NOWARN | __GFP_REPEAT > and if that fails, do vmalloc. > > To free, we can do > if (is_vmalloc_addr()) > vfree(); > else > kfree(); > > Hi Dan, were you going to make this change? Or prefer me to do it? -- MST

Hello. On 09/17/2013 11:21 AM, Michael S. Tsirkin wrote: > As vhost scsi device struct is large, if the device is > created on a busy system, kzalloc() might fail, so this patch does a > fallback to vzalloc(). > As vmalloc() adds overhead on data-path, add __GFP_REPEAT > to kzalloc() flags to do this fallback only when really needed. > Reported-by: Dan Aloni <alonid at stratoscale.com> > Signed-off-by: Michael S. Tsirkin <mst at redhat.com> > --- > I put this on my vhost fixes branch, intend to merge for 3.12. > Dan, could you plea...

...e.com> > > This extra indirection is likely to have measureable cost though. > > net core saw a similar problem, it was fixed in patch > net: allow large number of tx queues > > So let's do it in a similar way: try to allocate with > GFP_KERNEL | __GFP_NOWARN | __GFP_REPEAT > and if that fails, do vmalloc. > > To free, we can do > if (is_vmalloc_addr()) > vfree(); > else > kfree(); > > Hi Dan, were you going to make this change? Or prefer me to do it? -- MST

...2007-01-10.orig/arch/i386/mm/pgtable-xen.c 2007-01-10 13:33:54.000000000 +0100 +++ sle10-sp1-2007-01-10/arch/i386/mm/pgtable-xen.c 2007-01-10 14:14:47.000000000 +0100 @@ -238,23 +238,41 @@ struct page *pte_alloc_one(struct mm_str #ifdef CONFIG_HIGHPTE pte = alloc_pages(GFP_KERNEL|__GFP_HIGHMEM|__GFP_REPEAT|__GFP_ZERO, 0); + if (pte && PageHighMem(pte)) { + struct mmuext_op op; + + kmap_flush_unused(); + op.cmd = MMUEXT_PIN_L1_TABLE; + op.arg1.mfn = pfn_to_mfn(page_to_pfn(pte)); + BUG_ON(HYPERVISOR_mmuext_op(&op, 1, NULL, DOMID_SELF) < 0); + } #else pte = alloc_pages(GFP_KERNEL|...

Reposting with actual patches included. The following changes since commit 96b2e73c5471542cb9c622c4360716684f8797ed: Revert "net/mlx4_en: Use affinity hint" (2014-06-02 00:18:48 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git vhost-next for you to fetch changes up to 2ae76693b8bcabf370b981cd00c36cd41d33fabc: vhost:

Reposting with actual patches included. The following changes since commit 96b2e73c5471542cb9c622c4360716684f8797ed: Revert "net/mlx4_en: Use affinity hint" (2014-06-02 00:18:48 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git vhost-next for you to fetch changes up to 2ae76693b8bcabf370b981cd00c36cd41d33fabc: vhost:

...v->work_lock); INIT_LIST_HEAD(&dev->work_list); @@ -486,27 +491,36 @@ err_mm: } EXPORT_SYMBOL_GPL(vhost_dev_set_owner); -struct vhost_memory *vhost_dev_reset_owner_prepare(void) +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 kmalloc(offsetof(struct vhost_memory, regions), GFP_KERNEL); + return vhost_kvzalloc(sizeof(struct vhost_umem)); } EXPORT_SYMBOL_GPL(vhost_dev_reset_owner_prepare); /* Calle...

...v->work_lock); INIT_LIST_HEAD(&dev->work_list); @@ -486,27 +491,36 @@ err_mm: } EXPORT_SYMBOL_GPL(vhost_dev_set_owner); -struct vhost_memory *vhost_dev_reset_owner_prepare(void) +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 kmalloc(offsetof(struct vhost_memory, regions), GFP_KERNEL); + return vhost_kvzalloc(sizeof(struct vhost_umem)); } EXPORT_SYMBOL_GPL(vhost_dev_reset_owner_prepare); /* Calle...

...ed vhost_vsock_dev_open resp. > vhost_vsock_dev_open which are trying to use GFP_REPEAT for kmalloc. > 23cc5a991c7a ("vhost-net: extend device allocation to vmalloc") explains > the motivation as follows: > " > As vmalloc() adds overhead on a critical network path, add __GFP_REPEAT > to kzalloc() flags to do this fallback only when really needed. > " > > I am wondering whether vmalloc adds more overhead than GFP_REPEAT Yes but the GFP_REPEAT overhead is during allocation time. Using vmalloc means all accesses are slowed down. Allocation is not on data path,...

...v->work_lock); INIT_LIST_HEAD(&dev->work_list); @@ -486,27 +491,36 @@ err_mm: } EXPORT_SYMBOL_GPL(vhost_dev_set_owner); -struct vhost_memory *vhost_dev_reset_owner_prepare(void) +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 kmalloc(offsetof(struct vhost_memory, regions), GFP_KERNEL); + return vhost_kvzalloc(sizeof(struct vhost_umem)); } EXPORT_SYMBOL_GPL(vhost_dev_reset_owner_prepare); /* Calle...

...dev->work_list); > @@ -486,27 +491,36 @@ err_mm: > } > EXPORT_SYMBOL_GPL(vhost_dev_set_owner); > > -struct vhost_memory *vhost_dev_reset_owner_prepare(void) > +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 kmalloc(offsetof(struct vhost_memory, regions), GFP_KERNEL); > + return vhost_kvzalloc(sizeof(struct vhost_umem)); > } > E...

...dev->work_list); > @@ -486,27 +491,36 @@ err_mm: > } > EXPORT_SYMBOL_GPL(vhost_dev_set_owner); > > -struct vhost_memory *vhost_dev_reset_owner_prepare(void) > +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 kmalloc(offsetof(struct vhost_memory, regions), GFP_KERNEL); > + return vhost_kvzalloc(sizeof(struct vhost_umem)); > } > E...

...dev->work_list); > @@ -486,27 +491,36 @@ err_mm: > } > EXPORT_SYMBOL_GPL(vhost_dev_set_owner); > > -struct vhost_memory *vhost_dev_reset_owner_prepare(void) > +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 kmalloc(offsetof(struct vhost_memory, regions), GFP_KERNEL); > + return vhost_kvzalloc(sizeof(struct vhost_umem)); > } > E...

We have implemented hugepage support for guests in following manner In our implementation we added a parameter hugepage_num which is specified in the config file of the DomU. It is the number of hugepages that the guest is guaranteed to receive whenever the kernel asks for hugepage by using its boot time parameter or reserving after booting (eg. Using echo XX > /proc/sys/vm/nr_hugepages).