* [PATCH 19/29] drm/qxl: switch to drm_*{get,put} helpers
From: Cihangir Akturk @ 2017-08-03 11:58 UTC (permalink / raw)
Cc: David Airlie, linux-kernel, dri-devel, virtualization,
Cihangir Akturk, Dave Airlie
In-Reply-To: <1501761585-11757-1-git-send-email-cakturk@gmail.com>
drm_*_reference() and drm_*_unreference() functions are just
compatibility alias for drm_*_get() and drm_*_put() adn should not be
used by new code. So convert all users of compatibility functions to use
the new APIs.
Signed-off-by: Cihangir Akturk <cakturk@gmail.com>
---
drivers/gpu/drm/qxl/qxl_display.c | 4 ++--
drivers/gpu/drm/qxl/qxl_dumb.c | 2 +-
drivers/gpu/drm/qxl/qxl_fb.c | 6 +++---
drivers/gpu/drm/qxl/qxl_gem.c | 2 +-
drivers/gpu/drm/qxl/qxl_ioctl.c | 4 ++--
drivers/gpu/drm/qxl/qxl_object.c | 6 +++---
6 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_display.c b/drivers/gpu/drm/qxl/qxl_display.c
index 03fe182..7aa5097 100644
--- a/drivers/gpu/drm/qxl/qxl_display.c
+++ b/drivers/gpu/drm/qxl/qxl_display.c
@@ -306,7 +306,7 @@ void qxl_user_framebuffer_destroy(struct drm_framebuffer *fb)
{
struct qxl_framebuffer *qxl_fb = to_qxl_framebuffer(fb);
- drm_gem_object_unreference_unlocked(qxl_fb->obj);
+ drm_gem_object_put_unlocked(qxl_fb->obj);
drm_framebuffer_cleanup(fb);
kfree(qxl_fb);
}
@@ -1109,7 +1109,7 @@ qxl_user_framebuffer_create(struct drm_device *dev,
ret = qxl_framebuffer_init(dev, qxl_fb, mode_cmd, obj, &qxl_fb_funcs);
if (ret) {
kfree(qxl_fb);
- drm_gem_object_unreference_unlocked(obj);
+ drm_gem_object_put_unlocked(obj);
return NULL;
}
diff --git a/drivers/gpu/drm/qxl/qxl_dumb.c b/drivers/gpu/drm/qxl/qxl_dumb.c
index 5e65d5d..a0c9e73 100644
--- a/drivers/gpu/drm/qxl/qxl_dumb.c
+++ b/drivers/gpu/drm/qxl/qxl_dumb.c
@@ -81,6 +81,6 @@ int qxl_mode_dumb_mmap(struct drm_file *file_priv,
return -ENOENT;
qobj = gem_to_qxl_bo(gobj);
*offset_p = qxl_bo_mmap_offset(qobj);
- drm_gem_object_unreference_unlocked(gobj);
+ drm_gem_object_put_unlocked(gobj);
return 0;
}
diff --git a/drivers/gpu/drm/qxl/qxl_fb.c b/drivers/gpu/drm/qxl/qxl_fb.c
index 573e7e9..47a25b0 100644
--- a/drivers/gpu/drm/qxl/qxl_fb.c
+++ b/drivers/gpu/drm/qxl/qxl_fb.c
@@ -95,7 +95,7 @@ static void qxlfb_destroy_pinned_object(struct drm_gem_object *gobj)
qxl_bo_kunmap(qbo);
qxl_bo_unpin(qbo);
- drm_gem_object_unreference_unlocked(gobj);
+ drm_gem_object_put_unlocked(gobj);
}
int qxl_get_handle_for_primary_fb(struct qxl_device *qdev,
@@ -320,11 +320,11 @@ static int qxlfb_create(struct qxl_fbdev *qfbdev,
qxl_bo_unpin(qbo);
}
if (fb && ret) {
- drm_gem_object_unreference_unlocked(gobj);
+ drm_gem_object_put_unlocked(gobj);
drm_framebuffer_cleanup(fb);
kfree(fb);
}
- drm_gem_object_unreference_unlocked(gobj);
+ drm_gem_object_put_unlocked(gobj);
return ret;
}
diff --git a/drivers/gpu/drm/qxl/qxl_gem.c b/drivers/gpu/drm/qxl/qxl_gem.c
index 85f5467..f5c1e78 100644
--- a/drivers/gpu/drm/qxl/qxl_gem.c
+++ b/drivers/gpu/drm/qxl/qxl_gem.c
@@ -98,7 +98,7 @@ int qxl_gem_object_create_with_handle(struct qxl_device *qdev,
return r;
/* drop reference from allocate - handle holds it now */
*qobj = gem_to_qxl_bo(gobj);
- drm_gem_object_unreference_unlocked(gobj);
+ drm_gem_object_put_unlocked(gobj);
return 0;
}
diff --git a/drivers/gpu/drm/qxl/qxl_ioctl.c b/drivers/gpu/drm/qxl/qxl_ioctl.c
index 0b82a87..dfefd45 100644
--- a/drivers/gpu/drm/qxl/qxl_ioctl.c
+++ b/drivers/gpu/drm/qxl/qxl_ioctl.c
@@ -121,7 +121,7 @@ static int qxlhw_handle_to_bo(struct drm_file *file_priv, uint64_t handle,
qobj = gem_to_qxl_bo(gobj);
ret = qxl_release_list_add(release, qobj);
- drm_gem_object_unreference_unlocked(gobj);
+ drm_gem_object_put_unlocked(gobj);
if (ret)
return ret;
@@ -342,7 +342,7 @@ static int qxl_update_area_ioctl(struct drm_device *dev, void *data,
qxl_bo_unreserve(qobj);
out:
- drm_gem_object_unreference_unlocked(gobj);
+ drm_gem_object_put_unlocked(gobj);
return ret;
}
diff --git a/drivers/gpu/drm/qxl/qxl_object.c b/drivers/gpu/drm/qxl/qxl_object.c
index 9a7eef7..cdf1455 100644
--- a/drivers/gpu/drm/qxl/qxl_object.c
+++ b/drivers/gpu/drm/qxl/qxl_object.c
@@ -211,13 +211,13 @@ void qxl_bo_unref(struct qxl_bo **bo)
if ((*bo) == NULL)
return;
- drm_gem_object_unreference_unlocked(&(*bo)->gem_base);
+ drm_gem_object_put_unlocked(&(*bo)->gem_base);
*bo = NULL;
}
struct qxl_bo *qxl_bo_ref(struct qxl_bo *bo)
{
- drm_gem_object_reference(&bo->gem_base);
+ drm_gem_object_get(&bo->gem_base);
return bo;
}
@@ -316,7 +316,7 @@ void qxl_bo_force_delete(struct qxl_device *qdev)
list_del_init(&bo->list);
mutex_unlock(&qdev->gem.mutex);
/* this should unref the ttm bo */
- drm_gem_object_unreference_unlocked(&bo->gem_base);
+ drm_gem_object_put_unlocked(&bo->gem_base);
}
}
--
2.7.4
^ permalink raw reply related
* [PATCH 07/29] drm/cirrus: switch to drm_*{get,put} helpers
From: Cihangir Akturk @ 2017-08-03 11:58 UTC (permalink / raw)
Cc: Boris Brezillon, Archit Taneja, David Airlie, Daniel Vetter,
linux-kernel, dri-devel, virtualization, Cihangir Akturk,
Laurent Pinchart, Alex Deucher, Dave Airlie,
Gabriel Krisman Bertazi, Ville Syrjälä
In-Reply-To: <1501761585-11757-1-git-send-email-cakturk@gmail.com>
drm_*_reference() and drm_*_unreference() functions are just
compatibility alias for drm_*_get() and drm_*_put() adn should not be
used by new code. So convert all users of compatibility functions to use
the new APIs.
Signed-off-by: Cihangir Akturk <cakturk@gmail.com>
---
drivers/gpu/drm/cirrus/cirrus_fbdev.c | 2 +-
drivers/gpu/drm/cirrus/cirrus_main.c | 10 +++++-----
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/cirrus/cirrus_fbdev.c b/drivers/gpu/drm/cirrus/cirrus_fbdev.c
index 7fa58ee..c0b9a29 100644
--- a/drivers/gpu/drm/cirrus/cirrus_fbdev.c
+++ b/drivers/gpu/drm/cirrus/cirrus_fbdev.c
@@ -252,7 +252,7 @@ static int cirrus_fbdev_destroy(struct drm_device *dev,
drm_fb_helper_unregister_fbi(&gfbdev->helper);
if (gfb->obj) {
- drm_gem_object_unreference_unlocked(gfb->obj);
+ drm_gem_object_put_unlocked(gfb->obj);
gfb->obj = NULL;
}
diff --git a/drivers/gpu/drm/cirrus/cirrus_main.c b/drivers/gpu/drm/cirrus/cirrus_main.c
index e7fc95f..b5f5285 100644
--- a/drivers/gpu/drm/cirrus/cirrus_main.c
+++ b/drivers/gpu/drm/cirrus/cirrus_main.c
@@ -18,7 +18,7 @@ static void cirrus_user_framebuffer_destroy(struct drm_framebuffer *fb)
{
struct cirrus_framebuffer *cirrus_fb = to_cirrus_framebuffer(fb);
- drm_gem_object_unreference_unlocked(cirrus_fb->obj);
+ drm_gem_object_put_unlocked(cirrus_fb->obj);
drm_framebuffer_cleanup(fb);
kfree(fb);
}
@@ -67,13 +67,13 @@ cirrus_user_framebuffer_create(struct drm_device *dev,
cirrus_fb = kzalloc(sizeof(*cirrus_fb), GFP_KERNEL);
if (!cirrus_fb) {
- drm_gem_object_unreference_unlocked(obj);
+ drm_gem_object_put_unlocked(obj);
return ERR_PTR(-ENOMEM);
}
ret = cirrus_framebuffer_init(dev, cirrus_fb, mode_cmd, obj);
if (ret) {
- drm_gem_object_unreference_unlocked(obj);
+ drm_gem_object_put_unlocked(obj);
kfree(cirrus_fb);
return ERR_PTR(ret);
}
@@ -261,7 +261,7 @@ int cirrus_dumb_create(struct drm_file *file,
return ret;
ret = drm_gem_handle_create(file, gobj, &handle);
- drm_gem_object_unreference_unlocked(gobj);
+ drm_gem_object_put_unlocked(gobj);
if (ret)
return ret;
@@ -310,7 +310,7 @@ cirrus_dumb_mmap_offset(struct drm_file *file,
bo = gem_to_cirrus_bo(obj);
*offset = cirrus_bo_mmap_offset(bo);
- drm_gem_object_unreference_unlocked(obj);
+ drm_gem_object_put_unlocked(obj);
return 0;
}
--
2.7.4
^ permalink raw reply related
* [PATCH 06/29] drm/bochs: switch to drm_*{get,put} helpers
From: Cihangir Akturk @ 2017-08-03 11:58 UTC (permalink / raw)
Cc: David Airlie, linux-kernel, dri-devel, virtualization,
Cihangir Akturk
In-Reply-To: <1501761585-11757-1-git-send-email-cakturk@gmail.com>
drm_*_reference() and drm_*_unreference() functions are just
compatibility alias for drm_*_get() and drm_*_put() adn should not be
used by new code. So convert all users of compatibility functions to use
the new APIs.
Signed-off-by: Cihangir Akturk <cakturk@gmail.com>
---
drivers/gpu/drm/bochs/bochs_fbdev.c | 2 +-
drivers/gpu/drm/bochs/bochs_mm.c | 10 +++++-----
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/bochs/bochs_fbdev.c b/drivers/gpu/drm/bochs/bochs_fbdev.c
index c38deff..502f9d9 100644
--- a/drivers/gpu/drm/bochs/bochs_fbdev.c
+++ b/drivers/gpu/drm/bochs/bochs_fbdev.c
@@ -145,7 +145,7 @@ static int bochs_fbdev_destroy(struct bochs_device *bochs)
drm_fb_helper_unregister_fbi(&bochs->fb.helper);
if (gfb->obj) {
- drm_gem_object_unreference_unlocked(gfb->obj);
+ drm_gem_object_put_unlocked(gfb->obj);
gfb->obj = NULL;
}
diff --git a/drivers/gpu/drm/bochs/bochs_mm.c b/drivers/gpu/drm/bochs/bochs_mm.c
index c4cadb6..881b784 100644
--- a/drivers/gpu/drm/bochs/bochs_mm.c
+++ b/drivers/gpu/drm/bochs/bochs_mm.c
@@ -417,7 +417,7 @@ int bochs_dumb_create(struct drm_file *file, struct drm_device *dev,
return ret;
ret = drm_gem_handle_create(file, gobj, &handle);
- drm_gem_object_unreference_unlocked(gobj);
+ drm_gem_object_put_unlocked(gobj);
if (ret)
return ret;
@@ -457,7 +457,7 @@ int bochs_dumb_mmap_offset(struct drm_file *file, struct drm_device *dev,
bo = gem_to_bochs_bo(obj);
*offset = bochs_bo_mmap_offset(bo);
- drm_gem_object_unreference_unlocked(obj);
+ drm_gem_object_put_unlocked(obj);
return 0;
}
@@ -467,7 +467,7 @@ static void bochs_user_framebuffer_destroy(struct drm_framebuffer *fb)
{
struct bochs_framebuffer *bochs_fb = to_bochs_framebuffer(fb);
- drm_gem_object_unreference_unlocked(bochs_fb->obj);
+ drm_gem_object_put_unlocked(bochs_fb->obj);
drm_framebuffer_cleanup(fb);
kfree(fb);
}
@@ -518,13 +518,13 @@ bochs_user_framebuffer_create(struct drm_device *dev,
bochs_fb = kzalloc(sizeof(*bochs_fb), GFP_KERNEL);
if (!bochs_fb) {
- drm_gem_object_unreference_unlocked(obj);
+ drm_gem_object_put_unlocked(obj);
return ERR_PTR(-ENOMEM);
}
ret = bochs_framebuffer_init(dev, bochs_fb, mode_cmd, obj);
if (ret) {
- drm_gem_object_unreference_unlocked(obj);
+ drm_gem_object_put_unlocked(obj);
kfree(bochs_fb);
return ERR_PTR(ret);
}
--
2.7.4
^ permalink raw reply related
* [PATCH 00/29] DRM API conversions
From: Cihangir Akturk @ 2017-08-03 11:58 UTC (permalink / raw)
Cc: Xinliang Liu, Benjamin Herrenschmidt, dri-devel, Sumit Semwal,
Alex Xie, Chunming Zhou, linux-samsung-soc, Ben Skeggs,
Andrey Grodzovsky, Masahiro Yamada, etnaviv, Sean Paul,
Dave Airlie, Wei Yongjun, Nicolai Hähnle, Greg Kroah-Hartman,
Michel Dänzer, linux-kernel, Alex Deucher, Ken Wang,
Andrew Morton, freedreno
This patch set replaces the occurrences of drm_*_reference() and
drm_*_unreference() with the new drm_*_get() and drm_*_put() functions.
All patches in the series do the same thing, converting to the new APIs.
I created patches per DRM driver as suggested by Daniel Vetter.
Background:
In the kernel, reference counting APIs use *_get(), *_put() style naming
to reference-count the objects. But DRM subsystem uses a different
naming for them such as *_reference(), *_unreference() which is
inconsistent with the other reference counting APIs in the kernel. To
solve this consistency issue, Thierry Reding introduced a couple of
functions and compatibility aliases in the following commits for them.
commit 020a218f95bd3ceff7dd1022ff7ebc0497bc7bf9
Author: Thierry Reding <treding@nvidia.com>
Date: Tue Feb 28 15:46:38 2017 +0100
drm: Introduce drm_mode_object_{get,put}()
commit ad09360750afa18a0a0ce0253d6ea6033abc22e7
Author: Thierry Reding <treding@nvidia.com>
Date: Tue Feb 28 15:46:39 2017 +0100
drm: Introduce drm_connector_{get,put}()
commit a4a69da06bc11a937a6e417938b1bb698ee1fa46
Author: Thierry Reding <treding@nvidia.com>
Date: Tue Feb 28 15:46:40 2017 +0100
drm: Introduce drm_framebuffer_{get,put}()
commit e6b62714e87c8811d5564b6a0738dcde63a51774
Author: Thierry Reding <treding@nvidia.com>
Date: Tue Feb 28 15:46:41 2017 +0100
drm: Introduce drm_gem_object_{get,put}()
commit 6472e5090be7c78749a3c279b4faae87ab835c40
Author: Thierry Reding <treding@nvidia.com>
Date: Tue Feb 28 15:46:42 2017 +0100
drm: Introduce drm_property_blob_{get,put}()
This patch set was generated using the following shell script:
#!/bin/sh
path=$1
do_replace() {
local pattern=$1
local replacement=$2
git grep -lw "${pattern}" -- "${path}/*.[hc]" |\
xargs -r sed -i "s/\b$pattern\b/$replacement/g"
}
do_replace drm_mode_object_reference drm_mode_object_get
do_replace drm_mode_object_unreference drm_mode_object_put
do_replace drm_connector_reference drm_connector_get
do_replace drm_connector_unreference drm_connector_put
do_replace drm_framebuffer_reference drm_framebuffer_get
do_replace drm_framebuffer_unreference drm_framebuffer_put
do_replace drm_gem_object_reference drm_gem_object_get
do_replace drm_gem_object_unreference drm_gem_object_put
do_replace __drm_gem_object_unreference __drm_gem_object_put
do_replace drm_gem_object_unreference_unlocked drm_gem_object_put_unlocked
do_replace drm_property_reference_blob drm_property_blob_get
do_replace drm_property_unreference_blob drm_property_blob_put
Cihangir Akturk (29):
drm/amdgpu: switch to drm_*{get,put} helpers
drm: mali-dp: switch to drm_*{get,put} helpers
drm/armada: switch to drm_*{get,put} helpers
drm/ast: switch to drm_*{get,put} helpers
drm/atmel-hlcdc: switch to drm_*{get,put} helpers
drm/bochs: switch to drm_*{get,put} helpers
drm/cirrus: switch to drm_*{get,put} helpers
drm/etnaviv: switch to drm_*{get,put} helpers
drm/exynos: switch to drm_*{get,put} helpers
drm/gma500: switch to drm_*{get,put} helpers
drm/hisilicon: switch to drm_*{get,put} helpers
drm/i915: switch to drm_*{get,put} helpers
drm/imx: switch to drm_*{get,put} helpers
drm/mediatek: switch to drm_*{get,put} helpers
drm/mgag200: switch to drm_*{get,put} helpers
drm/msm: switch to drm_*{get,put} helpers
drm/nouveau: switch to drm_*{get,put} helpers
drm/omap: switch to drm_*{get,put} helpers
drm/qxl: switch to drm_*{get,put} helpers
drm/radeon: switch to drm_*{get,put} helpers
drm/rockchip: switch to drm_*{get,put} helpers
drm/tegra: switch to drm_*{get,put} helpers
drm/tilcdc: switch to drm_*{get,put} helpers
drm/udl: switch to drm_*{get,put} helpers
drm/vc4: switch to drm_*{get,put} helpers
drm/vgem: switch to drm_*{get,put} helpers
drm/virtio: switch to drm_*{get,put} helpers
drm/vmwgfx: switch to drm_*{get,put} helpers
staging: vboxvideo: switch to drm_*{get,put} helpers
drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 6 ++---
drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c | 4 +--
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 22 ++++++++---------
drivers/gpu/drm/amd/amdgpu/dce_v10_0.c | 6 ++---
drivers/gpu/drm/amd/amdgpu/dce_v11_0.c | 6 ++---
drivers/gpu/drm/amd/amdgpu/dce_v6_0.c | 6 ++---
drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 6 ++---
drivers/gpu/drm/arm/malidp_planes.c | 2 +-
drivers/gpu/drm/armada/armada_crtc.c | 22 ++++++++---------
drivers/gpu/drm/armada/armada_drv.c | 2 +-
drivers/gpu/drm/armada/armada_fb.c | 8 +++---
drivers/gpu/drm/armada/armada_fbdev.c | 6 ++---
drivers/gpu/drm/armada/armada_gem.c | 14 +++++------
drivers/gpu/drm/armada/armada_overlay.c | 4 +--
drivers/gpu/drm/ast/ast_fb.c | 2 +-
drivers/gpu/drm/ast/ast_main.c | 10 ++++----
drivers/gpu/drm/ast/ast_mode.c | 6 ++---
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 8 +++---
drivers/gpu/drm/bochs/bochs_fbdev.c | 2 +-
drivers/gpu/drm/bochs/bochs_mm.c | 10 ++++----
drivers/gpu/drm/cirrus/cirrus_fbdev.c | 2 +-
drivers/gpu/drm/cirrus/cirrus_main.c | 10 ++++----
drivers/gpu/drm/etnaviv/etnaviv_drv.c | 8 +++---
drivers/gpu/drm/etnaviv/etnaviv_gem.c | 20 +++++++--------
drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c | 2 +-
drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c | 4 +--
drivers/gpu/drm/exynos/exynos_drm_fb.c | 4 +--
drivers/gpu/drm/exynos/exynos_drm_gem.c | 12 ++++-----
drivers/gpu/drm/exynos/exynos_drm_plane.c | 2 +-
drivers/gpu/drm/gma500/framebuffer.c | 4 +--
drivers/gpu/drm/gma500/gem.c | 4 +--
drivers/gpu/drm/gma500/gma_display.c | 6 ++---
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c | 4 +--
drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c | 8 +++---
drivers/gpu/drm/i915/i915_gem_object.h | 10 ++++----
drivers/gpu/drm/i915/intel_display.c | 24 +++++++++---------
drivers/gpu/drm/i915/intel_dp_mst.c | 2 +-
drivers/gpu/drm/i915/intel_fbdev.c | 4 +--
drivers/gpu/drm/imx/ipuv3-crtc.c | 2 +-
drivers/gpu/drm/mediatek/mtk_drm_fb.c | 4 +--
drivers/gpu/drm/mediatek/mtk_drm_gem.c | 4 +--
drivers/gpu/drm/mgag200/mgag200_cursor.c | 2 +-
drivers/gpu/drm/mgag200/mgag200_fb.c | 4 +--
drivers/gpu/drm/mgag200/mgag200_main.c | 10 ++++----
drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 10 ++++----
drivers/gpu/drm/msm/adreno/a5xx_power.c | 2 +-
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 2 +-
drivers/gpu/drm/msm/mdp/mdp4/mdp4_crtc.c | 6 ++---
drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c | 2 +-
drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c | 2 +-
drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 4 +--
drivers/gpu/drm/msm/msm_drv.c | 8 +++---
drivers/gpu/drm/msm/msm_fb.c | 4 +--
drivers/gpu/drm/msm/msm_fbdev.c | 2 +-
drivers/gpu/drm/msm/msm_gem.c | 8 +++---
drivers/gpu/drm/msm/msm_gem_submit.c | 4 +--
drivers/gpu/drm/msm/msm_gpu.c | 4 +--
drivers/gpu/drm/msm/msm_ringbuffer.c | 2 +-
drivers/gpu/drm/nouveau/dispnv04/crtc.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_abi16.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_display.c | 8 +++---
drivers/gpu/drm/nouveau/nouveau_fbcon.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_gem.c | 14 +++++------
drivers/gpu/drm/nouveau/nv50_display.c | 2 +-
drivers/gpu/drm/omapdrm/omap_drv.c | 2 +-
drivers/gpu/drm/omapdrm/omap_fb.c | 4 +--
drivers/gpu/drm/omapdrm/omap_fbdev.c | 2 +-
drivers/gpu/drm/omapdrm/omap_gem.c | 4 +--
drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c | 2 +-
drivers/gpu/drm/qxl/qxl_display.c | 4 +--
drivers/gpu/drm/qxl/qxl_dumb.c | 2 +-
drivers/gpu/drm/qxl/qxl_fb.c | 6 ++---
drivers/gpu/drm/qxl/qxl_gem.c | 2 +-
drivers/gpu/drm/qxl/qxl_ioctl.c | 4 +--
drivers/gpu/drm/qxl/qxl_object.c | 6 ++---
drivers/gpu/drm/radeon/radeon_cs.c | 2 +-
drivers/gpu/drm/radeon/radeon_cursor.c | 6 ++---
drivers/gpu/drm/radeon/radeon_display.c | 12 ++++-----
drivers/gpu/drm/radeon/radeon_fb.c | 4 +--
drivers/gpu/drm/radeon/radeon_gem.c | 30 +++++++++++------------
drivers/gpu/drm/radeon/radeon_object.c | 2 +-
drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 6 ++---
drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c | 2 +-
drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 4 +--
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 4 +--
drivers/gpu/drm/tegra/drm.c | 12 ++++-----
drivers/gpu/drm/tegra/fb.c | 8 +++---
drivers/gpu/drm/tegra/gem.c | 10 ++++----
drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 6 ++---
drivers/gpu/drm/udl/udl_fb.c | 6 ++---
drivers/gpu/drm/udl/udl_gem.c | 4 +--
drivers/gpu/drm/vc4/vc4_bo.c | 12 ++++-----
drivers/gpu/drm/vc4/vc4_crtc.c | 6 ++---
drivers/gpu/drm/vc4/vc4_gem.c | 14 +++++------
drivers/gpu/drm/vc4/vc4_kms.c | 2 +-
drivers/gpu/drm/vgem/vgem_drv.c | 4 +--
drivers/gpu/drm/vgem/vgem_fence.c | 2 +-
drivers/gpu/drm/virtio/virtgpu_display.c | 4 +--
drivers/gpu/drm/virtio/virtgpu_gem.c | 4 +--
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 14 +++++------
drivers/gpu/drm/vmwgfx/vmwgfx_fb.c | 2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c | 4 +--
drivers/staging/vboxvideo/vbox_fb.c | 2 +-
drivers/staging/vboxvideo/vbox_main.c | 8 +++---
drivers/staging/vboxvideo/vbox_mode.c | 2 +-
107 files changed, 319 insertions(+), 319 deletions(-)
--
2.7.4
^ permalink raw reply
* Re: [virtio-dev] repost: af_packet vs virtio (was packed ring layout proposal v2)
From: Michael S. Tsirkin @ 2017-08-02 13:50 UTC (permalink / raw)
To: Steven Luong
Cc: virtio-dev, kvm, netdev, john.fastabend, virtualization,
alexei.starovoitov
In-Reply-To: <CAJR92jnV1VgBs567QNjO1fHKDgMX=1j1aJJ2gK-TqMB5E1=fvw@mail.gmail.com>
On Tue, Aug 01, 2017 at 08:54:27PM -0700, Steven Luong wrote:
> * Descriptor ring:
>
> Guest adds descriptors with unique index values and DESC_HW set in flags.
> Host overwrites used descriptors with correct len, index, and DESC_HW
> clear. Flags are always set/cleared last.
>
> #define DESC_HW 0x0080
>
> struct desc {
> __le64 addr;
> __le32 len;
> __le16 index;
> __le16 flags;
> };
>
> When DESC_HW is set, descriptor belongs to device. When it is clear,
> it belongs to the driver.
>
> We can use 1 bit to set direction
> /* This marks a buffer as write-only (otherwise read-only). */
> #define VRING_DESC_F_WRITE 2
>
> * Scatter/gather support
>
> We can use 1 bit to chain s/g entries in a request, same as virtio 1.0:
>
> /* This marks a buffer as continuing via the next field. */
>
>
> This comment here is confusing to me. In 1.0, virtq_desc has the next field.
> When the flag VRING_DESC_F_NEXT is set, the next entry to continue is specified
> in the next field.
>
> Here in 1.1, struct desc does not have the next field, only addr, len, index,
> and flags. So when VRING_DESC_F_NEXT is set in struct desc's flags field, where
> is the next entry to continue the current descriptor, the entry immediately
> following the current entry? ie, if the current entry is at index 10 in the
> descriptor table and its flags is set for VRING_DESC_F_NEXT, is the entry
> continuing the current entry in index 11?
>
> Steven
Exactly, you got it right.
^ permalink raw reply
* [PATCH 3/3] char: virtio: constify attribute_group structures.
From: Arvind Yadav @ 2017-08-02 11:21 UTC (permalink / raw)
To: arnd, gregkh, mark.gross, amit; +Cc: linux-kernel, virtualization
attribute_group are not supposed to change at runtime. All functions
working with attribute_group provided by <linux/sysfs.h> work with
const attribute_group. So mark the non-const structs as const.
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
---
drivers/char/virtio_console.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/char/virtio_console.c b/drivers/char/virtio_console.c
index ad843eb..06bd635 100644
--- a/drivers/char/virtio_console.c
+++ b/drivers/char/virtio_console.c
@@ -1308,7 +1308,7 @@ static ssize_t show_port_name(struct device *dev,
NULL
};
-static struct attribute_group port_attribute_group = {
+static const struct attribute_group port_attribute_group = {
.name = NULL, /* put in device directory */
.attrs = port_sysfs_entries,
};
--
1.9.1
^ permalink raw reply related
* Re: [virtio-dev] repost: af_packet vs virtio (was packed ring layout proposal v2)
From: Steven Luong @ 2017-08-02 3:54 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: virtio-dev, kvm, netdev, john.fastabend, virtualization,
alexei.starovoitov
In-Reply-To: <20170414054318-mutt-send-email-mst@kernel.org>
[-- Attachment #1.1: Type: text/plain, Size: 8689 bytes --]
Michael,
I have a question on s/g
On Thu, Apr 13, 2017 at 7:50 PM, Michael S. Tsirkin <mst@redhat.com> wrote:
> On Fri, Apr 14, 2017 at 05:42:58AM +0300, Michael S. Tsirkin wrote:
> > Hi all, I wanted to raise the question of similarities between virtio
> > and new zero copy af_packet interfaces.
> >
> > First I would like to mention that virtio device development isn't spec
> > limited - spec is there to help interoperability and add peace of mind
> > for people worried about IPR.
> >
> > So I tend to accept patches without requiring people write it up in the
> > spec as work on spec proceeds at its own pace - all I ask is that the
> > virtio mailing list is copied, this requires contributor to subscribe
> > and in the process contributor promises that it's ok for us to add this
> > to spec in the future.
> >
> > There shouldn't thus be a fundamental problem preventing use of virtio
> > format or reusing some of the code for af_packet, but it still might or
> > might not make sense - it was designed for CPU to CPU communication so
> > it seems to make sense though. So I would like that discussion to
> > happen even if we decide against.
> >
> > And even if people decide against, the problem space is very similar.
> You
> > can look up packed ring layout proposal v2 - should I repost here? Our
> > prototyping shows significant performance improvements from using it as
> > compared to head/tail layout.
> >
> > To start this discission I'm going to reply to this email reposting a
> > copy of the simplified virtio layout that might be appropriate for
> > af_packet as well.
>
> Here's the repost (slightly cut down) sorry about the duplicates.
>
> The idea is to have a r/w descriptor in a ring structure,
> replacing the used and available ring, index and descriptor
> buffer.
>
> * Descriptor ring:
>
> Guest adds descriptors with unique index values and DESC_HW set in flags.
> Host overwrites used descriptors with correct len, index, and DESC_HW
> clear. Flags are always set/cleared last.
>
> #define DESC_HW 0x0080
>
> struct desc {
> __le64 addr;
> __le32 len;
> __le16 index;
> __le16 flags;
> };
>
> When DESC_HW is set, descriptor belongs to device. When it is clear,
> it belongs to the driver.
>
> We can use 1 bit to set direction
> /* This marks a buffer as write-only (otherwise read-only). */
> #define VRING_DESC_F_WRITE 2
>
> * Scatter/gather support
>
> We can use 1 bit to chain s/g entries in a request, same as virtio 1.0:
>
> /* This marks a buffer as continuing via the next field. */
>
This comment here is confusing to me. In 1.0, virtq_desc has the next
field. When the flag VRING_DESC_F_NEXT is set, the next entry to continue
is specified in the next field.
Here in 1.1, struct desc does not have the next field, only addr, len,
index, and flags. So when VRING_DESC_F_NEXT is set in struct desc's flags
field, where is the next entry to continue the current descriptor, the
entry immediately following the current entry? ie, if the current entry is
at index 10 in the descriptor table and its flags is set for
VRING_DESC_F_NEXT, is the entry continuing the current entry in index 11?
Steven
> #define VRING_DESC_F_NEXT 1
>
> Unlike virtio 1.0, all descriptors must have distinct ID values.
>
> Also unlike virtio 1.0, use of this flag will be an optional feature
> (e.g. VIRTIO_F_DESC_NEXT) so both devices and drivers can opt out of it.
>
> * Indirect buffers
>
> Can be marked like in virtio 1.0:
>
> /* This means the buffer contains a table of buffer descriptors. */
> #define VRING_DESC_F_INDIRECT 4
>
> Unlike virtio 1.0, this is a table, not a list:
> struct indirect_descriptor_table {
> /* The actual descriptors (16 bytes each) */
> struct virtq_desc desc[len / 16];
> };
>
> The first descriptor is located at start of the indirect descriptor
> table, additional indirect descriptors come immediately afterwards.
> DESC_F_WRITE is the only valid flag for descriptors in the indirect
> table. Others should be set to 0 and are ignored. id is also set to 0
> and should be ignored.
>
> virtio 1.0 seems to allow a s/g entry followed by
> an indirect descriptor. This does not seem useful,
> so we do not allow that anymore.
>
> This support would be an optional feature, same as in virtio 1.0
>
> * Batching descriptors:
>
> virtio 1.0 allows passing a batch of descriptors in both directions, by
> incrementing the used/avail index by values > 1. We can support this by
> chaining a list of descriptors through a bit the flags field.
> To allow use together with s/g, a different bit will be used.
>
> #define VRING_DESC_F_BATCH_NEXT 0x0010
>
> Batching works for both driver and device descriptors.
>
>
>
> * Processing descriptors in and out of order
>
> Device processing all descriptors in order can simply flip
> the DESC_HW bit as it is done with descriptors.
>
> Device can write descriptors out in order as they are used, overwriting
> descriptors that are there.
>
> Device must not use a descriptor until DESC_HW is set.
> It is only required to look at the first descriptor
> submitted.
>
> Driver must not overwrite a descriptor until DESC_HW is clear.
> It is only required to look at the first descriptor
> submitted.
>
> * Device specific descriptor flags
> We have a lot of unused space in the descriptor. This can be put to
> good use by reserving some flag bits for device use.
> For example, network device can set a bit to request
> that header in the descriptor is suppressed
> (in case it's all 0s anyway). This reduces cache utilization.
>
> Note: this feature can be supported in virtio 1.0 as well,
> as we have unused bits in both descriptor and used ring there.
>
> * Descriptor length in device descriptors
>
> virtio 1.0 places strict requirements on descriptor length. For example
> it must be 0 in used ring of TX VQ of a network device since nothing is
> written. In practice guests do not seem to use this, so we can simplify
> devices a bit by removing this requirement - if length is unused it
> should be ignored by driver.
>
> Some devices use identically-sized buffers in all descriptors.
> Ignoring length for driver descriptors there could be an option too.
>
> * Writing at an offset
>
> Some devices might want to write into some descriptors
> at an offset, the offset would be in config space,
> and a descriptor flag could indicate this:
>
> #define VRING_DESC_F_OFFSET 0x0020
>
> How exactly to use the offset would be device specific,
> for example it can be used to align beginning of packet
> in the 1st buffer for mergeable buffers to cache line boundary
> while also aligning rest of buffers.
>
> * Non power-of-2 ring sizes
>
> As the ring simply wraps around, there's no reason to
> require ring size to be power of two.
> It can be made a separate feature though.
>
>
> * Interrupt/event suppression
>
> virtio 1.0 has two mechanisms for suppression but only
> one can be used at a time. we pack them together
> in a structure - one for interrupts, one for notifications:
>
> struct event {
> __le16 idx;
> __le16 flags;
> }
>
> Both fields would be optional, with a feature bit:
> VIRTIO_F_EVENT_IDX
> VIRTIO_F_EVENT_FLAGS
>
> * Flags can be used like in virtio 1.0, by storing a special
> value there:
>
> #define VRING_F_EVENT_ENABLE 0x0
>
> #define VRING_F_EVENT_DISABLE 0x1
>
> * Event index would be in the range 0 to 2 * Queue Size
> (to detect wrap arounds) and wrap to 0 after that.
>
> The assumption is that each side maintains an internal
> descriptor counter 0 to 2 * Queue Size that wraps to 0.
> In that case, interrupt triggers when counter reaches
> the given value.
>
> * If both features are negotiated, a special flags value
> can be used to switch to event idx:
>
> #define VRING_F_EVENT_IDX 0x2
>
>
> * Prototype
>
> A partial prototype can be found under
> tools/virtio/ringtest/ring.c
>
> Test run:
> [mst@tuck ringtest]$ time ./ring
> real 0m0.399s
> user 0m0.791s
> sys 0m0.000s
> [mst@tuck ringtest]$ time ./virtio_ring_0_9
> real 0m0.503s
> user 0m0.999s
> sys 0m0.000s
>
> This seems to match the theoretical analysis showing marking
> descriptors themselves as invalid works better than a head/tail design.
> Future changes and enhancements can be tested against this prototype.
>
> A dpdk based implementation can be found here:
>
> git://dpdk.org/next/dpdk-next-virtio for-testing
>
>
>
> --
> MST
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
>
>
[-- Attachment #1.2: Type: text/html, Size: 10435 bytes --]
[-- Attachment #2: Type: text/plain, Size: 183 bytes --]
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [PATCH] mm: don't zero ballooned pages
From: Michael S. Tsirkin @ 2017-08-01 15:38 UTC (permalink / raw)
To: Michal Hocko
Cc: mawilcox, dave.hansen, linux-kernel, virtualization, linux-mm,
akpm, ZhenweiPi
In-Reply-To: <20170731083724.GF15767@dhcp22.suse.cz>
On Mon, Jul 31, 2017 at 10:37:24AM +0200, Michal Hocko wrote:
> On Mon 31-07-17 16:23:26, ZhenweiPi wrote:
> > On 07/31/2017 03:51 PM, Michal Hocko wrote:
> >
> > >On Mon 31-07-17 15:41:49, Wei Wang wrote:
> > >>>On 07/31/2017 02:55 PM, Michal Hocko wrote:
> > >>>> >On Mon 31-07-17 12:13:33, Wei Wang wrote:
> > >>>>> >>Ballooned pages will be marked as MADV_DONTNEED by the hypervisor and
> > >>>>> >>shouldn't be given to the host ksmd to scan.
> > >>>> >Could you point me where this MADV_DONTNEED is done, please?
> > >>>
> > >>>Sure. It's done in the hypervisor when the balloon pages are received.
> > >>>
> > >>>Please see line 40 at
> > >>>https://github.com/qemu/qemu/blob/master/hw/virtio/virtio-balloon.c
> > >And one more thing. I am not familiar with ksm much. But how is
> > >MADV_DONTNEED even helping? This madvise is not sticky - aka it will
> > >unmap the range without leaving any note behind. AFAICS the only way
> > >to have vma scanned is to have VM_MERGEABLE and that is an opt in:
> > >See Documentation/vm/ksm.txt
> > >"
> > >KSM only operates on those areas of address space which an application
> > >has advised to be likely candidates for merging, by using the madvise(2)
> > >system call: int madvise(addr, length, MADV_MERGEABLE).
> > >"
> > >
> > >So what exactly is going on here? The original patch looks highly
> > >suspicious as well. If somebody wants to make that memory mergable then
> > >the user of that memory should zero them out.
> >
> > Kernel starts a kthread named "ksmd". ksmd scans the VM_MERGEABLE
> > memory, and merge the same pages.(same page means memcmp(page1,
> > page2, PAGESIZE) == 0).
> >
> > Guest can not use ballooned pages, and these pages will not be accessed
> > in a long time. Kswapd on host will swap these pages out and get more
> > free memory.
> >
> > Rather than swapping, KSM has better performence. Presently pages in
> > the balloon device have random value, they usually cannot be merged.
> > So enqueue zero pages will resolve this problem.
> >
> > Because MADV_DONTNEED depends on host os capability and hypervisor capability,
> > I prefer to enqueue zero pages to balloon device and made this patch.
I think you should have hypervisor zero them out if it wants to then. Seems cleaner.
>
> So why exactly are we zeroying pages (and pay some cost for that) in
> guest when we do not know what host actually does with them?
I suspect this is some special hypervisor that somehow benefits from
this patch. It should just use a feature bit for its special needs
I think.
Michal is also exactly right that patches like this should come
with some performance numbers.
I'll post a patch adding virtio lists for mm/balloon_compaction.c
so that we notice when people tweak it like that.
> --
> Michal Hocko
> SUSE Labs
^ permalink raw reply
* [PATCH net] virtio_net: fix truesize for mergeable buffers
From: Michael S. Tsirkin @ 2017-07-31 18:49 UTC (permalink / raw)
To: linux-kernel; +Cc: netdev, virtualization, Seth Forshee, David Miller
Seth Forshee noticed a performance degradation with some workloads.
This turns out to be due to packet drops. Euan Kemp noticed that this
is because we drop all packets where length exceeds the truesize, but
for some packets we add in extra memory without updating the truesize.
This in turn was kept around unchanged from ab7db91705e95 ("virtio-net:
auto-tune mergeable rx buffer size for improved performance"). That
commit had an internal reason not to account for the extra space: not
enough bits to do it. No longer true so let's account for the allocated
length exactly.
Many thanks to Seth Forshee for the report and bisecting and Euan Kemp
for debugging the issue.
Fixes: 680557cf79f8 ("virtio_net: rework mergeable buffer handling")
Reported-by: Euan Kemp <euan.kemp@coreos.com>
Tested-by: Euan Kemp <euan.kemp@coreos.com>
Reported-by: Seth Forshee <seth.forshee@canonical.com>
Tested-by: Seth Forshee <seth.forshee@canonical.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
This patch is needed on stable as well.
drivers/net/virtio_net.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index f41ab0e..98f17b0 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -889,21 +889,20 @@ static int add_recvbuf_mergeable(struct virtnet_info *vi,
buf = (char *)page_address(alloc_frag->page) + alloc_frag->offset;
buf += headroom; /* advance address leaving hole at front of pkt */
- ctx = (void *)(unsigned long)len;
get_page(alloc_frag->page);
alloc_frag->offset += len + headroom;
hole = alloc_frag->size - alloc_frag->offset;
if (hole < len + headroom) {
/* To avoid internal fragmentation, if there is very likely not
* enough space for another buffer, add the remaining space to
- * the current buffer. This extra space is not included in
- * the truesize stored in ctx.
+ * the current buffer.
*/
len += hole;
alloc_frag->offset += hole;
}
sg_init_one(rq->sg, buf, len);
+ ctx = (void *)(unsigned long)len;
err = virtqueue_add_inbuf_ctx(rq->vq, rq->sg, 1, buf, ctx, gfp);
if (err < 0)
put_page(virt_to_head_page(buf));
--
MST
^ permalink raw reply related
* CFP SMARTGREENS 2018 - 7th Int.l Conf. on Smart Cities and Green ICT Systems (Funchal, Madeira/Portugal)
From: smartgreens @ 2017-07-31 15:45 UTC (permalink / raw)
To: virtualization
SUBMISSION DEADLINE
7th International Conference on Smart Cities and Green ICT Systems
Submission Deadline: October 16, 2017
http://www.smartgreens.org/
March 16 - 18, 2018
Funchal, Madeira, Portugal.
SMARTGREENS is organized in 4 major tracks:
- Energy-Aware Systems and Technologies
- Sustainable Computing and Systems
- Smart Cities and Smart Buildings
- Demos and Use-Cases
In Cooperation with IEEE Technical Area in Green Computing, Siemens, EDSO, APEA, OSGP Alliance.
A short list of presented papers will be selected so that revised and extended versions of these papers will be published by Springer.
All papers presented at the congress venue will also be available at the SCITEPRESS Digital Library (http://www.scitepress.org/DigitalLibrary/).
Should you have any question please don’t hesitate contacting me.
Kind regards,
SMARTGREENS Secretariat
Address: Av. D. Manuel I, 27A, 2º esq.
2910-595 Setubal, Portugal
Tel: +351 265 520 185
Fax: +351 265 520 186
Web: http://www.smartgreens.org/
e-mail: smartgreens.secretariat@insticc.org
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* CFP VEHITS 2018 - 4th Int.l Conf. on Vehicle Technology and Intelligent Transport Systems (Funchal, Madeira/Portugal)
From: vehits @ 2017-07-31 15:45 UTC (permalink / raw)
To: virtualization
SUBMISSION DEADLINE
4th International Conference on Vehicle Technology and Intelligent Transport Systems
Submission Deadline: October 16, 2017
http://www.vehits.org/
March 16 - 18, 2018
Funchal, Madeira, Portugal.
VEHITS is organized in 5 major tracks:
- Intelligent Vehicle Technologies
- Intelligent Transport Systems and Infrastructure
- Connected Vehicles
- Sustainable Transport
- Data Analtyics
In Cooperation with APVE, CVTA, ABVE, ITS Portugal.
With the presence of internationally distinguished keynote speakers:
Miguel A. Sotelo, Universidad de Alcalá, Spain
A short list of presented papers will be selected so that revised and extended versions of these papers will be published by Springer.
All papers presented at the congress venue will also be available at the SCITEPRESS Digital Library (http://www.scitepress.org/DigitalLibrary/).
Should you have any question please don’t hesitate contacting me.
Kind regards,
VEHITS Secretariat
Address: Av. D. Manuel I, 27A, 2º esq.
2910-595 Setubal, Portugal
Tel: +351 265 520 185
Fax: +351 265 520 186
Web: http://www.vehits.org/
e-mail: vehits.secretariat@insticc.org
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* CFP CLOSER 2018 - 8th Int.l Conf. on Cloud Computing and Services Science (Funchal, Madeira/Portugal)
From: closer @ 2017-07-31 15:45 UTC (permalink / raw)
To: virtualization
SUBMISSION DEADLINE
8th International Conference on Cloud Computing and Services Science
Submission Deadline: October 16, 2017
http://closer.scitevents.org/
March 19 - 21, 2018
Funchal, Madeira, Portugal.
CLOSER is organized in 9 major tracks:
- Services Science
- Data as a Service
- Cloud Operations
- Edge Cloud and Fog Computing
- Service Modelling and Analytics
- Mobile Cloud Computing
- Cloud Computing Fundamentals
- Cloud Computing Platforms and Applications
- Cloud Computing Enabling Technology
With the presence of internationally distinguished keynote speakers:
Mike Papazoglou, Tilburg University, Netherlands
Tobias Hoellwarth, EuroCloud Europe, Austria
A short list of presented papers will be selected so that revised and extended versions of these papers will be published by Springer.
All papers presented at the congress venue will also be available at the SCITEPRESS Digital Library (http://www.scitepress.org/DigitalLibrary/).
Should you have any question please don’t hesitate contacting me.
Kind regards,
CLOSER Secretariat
Address: Av. D. Manuel I, 27A, 2º esq.
2910-595 Setubal, Portugal
Tel: +351 265 520 184
Fax: +351 265 520 186
Web: http://closer.scitevents.org/
e-mail: closer.secretariat@insticc.org
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* CFP ICEIS 2018 - 20th Int.l Conf. on Enterprise Information Systems (Funchal, Madeira/Portugal)
From: iceis @ 2017-07-31 15:45 UTC (permalink / raw)
To: virtualization
SUBMISSION DEADLINE
20th International Conference on Enterprise Information Systems
Submission Deadline: October 18, 2017
http://www.iceis.org/
March 21 - 24, 2018
Funchal, Madeira, Portugal.
ICEIS is organized in 6 major tracks:
- Databases and Information Systems Integration
- Artificial Intelligence and Decision Support Systems
- Information Systems Analysis and Specification
- Software Agents and Internet Computing
- Human-Computer Interaction
- Enterprise Architecture
In Cooperation with SWIM, AAAI.
With the presence of internationally distinguished keynote speakers:
Alexander Brodsky, George Mason University, United States
Plamen Angelov, Lancaster University, United Kingdom
A short list of presented papers will be selected so that revised and extended versions of these papers will be published by Springer.
All papers presented at the congress venue will also be available at the SCITEPRESS Digital Library (http://www.scitepress.org/DigitalLibrary/).
Should you have any question please don’t hesitate contacting me.
Kind regards,
ICEIS Secretariat
Address: Av. D. Manuel I, 27A, 2º esq.
2910-595 Setubal, Portugal
Tel: +351 265 520 184
Fax: +351 265 520 186
Web: http://www.iceis.org/
e-mail: iceis.secretariat@insticc.org
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* CFP IoTBDS 2018 - 3rd Int.l Conf. on Internet of Things, Big Data and Security (Funchal, Madeira/Portugal)
From: iotbds @ 2017-07-31 15:44 UTC (permalink / raw)
To: virtualization
SUBMISSION DEADLINE
3rd International Conference on Internet of Things, Big Data and Security
Submission Deadline: October 16, 2017
http://iotbds.org/
March 19 - 21, 2018
Funchal, Madeira, Portugal.
IoTBDS is organized in 7 major tracks:
- Big Data Research
- Emerging Services and Analytics
- Internet of Things (IoT) Fundamentals
- Internet of Things (IoT) Applications
- Big Data for Multi-discipline Services
- Security, Privacy and Trust
- IoT Technologies
With the presence of internationally distinguished keynote speakers:
Tobias Hoellwarth, EuroCloud Europe, Austria
A short list of presented papers will be selected so that revised and extended versions of these papers will be published by Springer.
All papers presented at the congress venue will also be available at the SCITEPRESS Digital Library (http://www.scitepress.org/DigitalLibrary/).
Should you have any question please don’t hesitate contacting me.
Kind regards,
IoTBDS Secretariat
Address: Av. D. Manuel I, 27A, 2º esq.
2910-595 Setubal, Portugal
Tel: +351 265 520 184
Fax: +351 265 520 186
Web: http://iotbds.org/
e-mail: iotbds.secretariat@insticc.org
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [RFC] virtio-mem: paravirtualized memory
From: David Hildenbrand @ 2017-07-31 15:04 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Andrea Arcangeli, Pankaj Gupta, Rik van Riel, KVM,
qemu-devel@nongnu.org, virtualization@lists.linux-foundation.org,
linux-mm@kvack.org, Dan Williams
In-Reply-To: <20170731162757-mutt-send-email-mst@kernel.org>
On 31.07.2017 16:12, Michael S. Tsirkin wrote:
> On Fri, Jul 28, 2017 at 05:48:07PM +0200, David Hildenbrand wrote:
>> In general, a paravirtualized interface (for detection of PMEM regions)
>> might have one big advantage: not limited to certain architectures.
>
> What follows is a generic rant, and slightly offtopic -sorry about that.
> I thought it's worth replying to above since people sometimes propose
> random PV devices and portability is often the argument. I'd claim if
> its the only argument - its not a very good one.
Very good point. Thanks for that comment. I totally agree, that we have
to decide for which parts we really need a paravirtualized interface. We
already paravirtualized quite a lot (starting with clocks and mmios,
ending with network devices).
Related to fake DAX, think about this example (cc'ing Christian, so I
don't talk too much nonsense):
s390x hardware cannot map anything into the address space. Not even PCI
devices on s390x work that way. So the whole architecture (to this point
I am aware of) is built on this fact. We can indicate "valid memory
regions" to the guest via a standardized interface, but the guest will
simply treat it like RAM.
With virtualization, this is different. We can map whatever we want into
the guest address space, but we have to tell the guest that this area is
special. There is no ACPI on s390x to do that.
This implies, that for s390x, we could not support fake DAX, just
because we don't have ACPI. No fake DAX, no avoiding of page caches in
the guest. Which is something we _could_ avoid quite easily.
>
> One of the points of KVM is to try and reuse the infrastructure in Linux
> that runs containers/bare metal anyway. The more paravirtualized
> interfaces you build, the more effort you get to spend to maintain
> various aspects of the system. As optimizations force more and more
> paravirtualization into the picture, our solution has been to try to
> localize their effect, so you can mix and match paravirtualization and
> emulation, as well as enable a subset of PV things that makes sense. For
> example, virtio devices look more or less like PCI devices on systems
> that have PCI.
We make paravirtualized devices look like them, but what we (in most
cases) don't do is the following: Detect and use devices via a
!paravirtualized way and later on decide "oh, this device is special"
and treat it suddenly like a paravirtualized device*.
E.g. virtio-scsi, an unmodified guest will not simply detect and use,
say, a virtio-scsi attached disk. (unless I am very wrong on that point ;) )
*This might work for devices, where paravirtualization is e.g. just a
way to speedup things. But if paravirtualization is part of the concept
(fake DAX - we need that flush), this will not work.
In the words of s390x: indicate fake DAX as ordinary ram. The guest will
hotplug it and use it like ordinary ram. At that point, it is too late
to convert it logically into a disk.
What I think is the following: We need a way to advertise devices that
are mapped into the address space via a paravirtualized way. This could
e.g. be fake DAX devices or what virtio-mem's memory hotplug approach
tries to solve.
Basically what virtio-mem proposed: indicating devices in the form of
memory regions that are special to the guest via a paravirtualized
interface and providing paravirtualized features, that can (and even
have to) be used along with these special devices.
>
> It's not clear it applies here - memory overcommit on bare metal is
> kind of different.
Yes, there is no such thing as fine grained memory hot(un)plug on real
hardware.
--
Thanks,
David
^ permalink raw reply
* Re: [RFC] virtio-mem: paravirtualized memory
From: Michael S. Tsirkin @ 2017-07-31 14:12 UTC (permalink / raw)
To: David Hildenbrand
Cc: Andrea Arcangeli, Pankaj Gupta, Rik van Riel, KVM,
qemu-devel@nongnu.org, virtualization@lists.linux-foundation.org,
linux-mm@kvack.org, Dan Williams
In-Reply-To: <d5a1f1d2-f7c8-cacc-3267-ed6f7d2507ca@redhat.com>
On Fri, Jul 28, 2017 at 05:48:07PM +0200, David Hildenbrand wrote:
> In general, a paravirtualized interface (for detection of PMEM regions)
> might have one big advantage: not limited to certain architectures.
What follows is a generic rant, and slightly offtopic -sorry about that.
I thought it's worth replying to above since people sometimes propose
random PV devices and portability is often the argument. I'd claim if
its the only argument - its not a very good one.
One of the points of KVM is to try and reuse the infrastructure in Linux
that runs containers/bare metal anyway. The more paravirtualized
interfaces you build, the more effort you get to spend to maintain
various aspects of the system. As optimizations force more and more
paravirtualization into the picture, our solution has been to try to
localize their effect, so you can mix and match paravirtualization and
emulation, as well as enable a subset of PV things that makes sense. For
example, virtio devices look more or less like PCI devices on systems
that have PCI.
It's not clear it applies here - memory overcommit on bare metal is
kind of different.
--
MST
^ permalink raw reply
* Re: [PATCH v12 5/8] virtio-balloon: VIRTIO_BALLOON_F_SG
From: Wei Wang @ 2017-07-31 12:36 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: aarcange@redhat.com, virtio-dev@lists.oasis-open.org,
kvm@vger.kernel.org, qemu-devel@nongnu.org, amit.shah@redhat.com,
liliang.opensource@gmail.com, linux-kernel@vger.kernel.org,
virtualization@lists.linux-foundation.org, linux-mm@kvack.org,
yang.zhang.wz@gmail.com, quan.xu@aliyun.com,
cornelia.huck@de.ibm.com, pbonzini@redhat.com,
akpm@linux-foundation.org, mgorman@techsingularity.net
In-Reply-To: <20170730191911-mutt-send-email-mst@kernel.org>
On 07/31/2017 12:20 AM, Michael S. Tsirkin wrote:
> On Sun, Jul 30, 2017 at 07:18:33PM +0300, Michael S. Tsirkin wrote:
>> On Sun, Jul 30, 2017 at 05:59:17AM +0000, Wang, Wei W wrote:
>> That's a hypervisor implementation detail. From guest point of view,
>> discarding contents can not be distinguished from writing old contents.
>>
> Besides, ignoring the free page tricks, consider regular ballooning.
> We map page with DONTNEED then back with WILLNEED. Result is
> getting a zero page. So at least one of deflate/inflate should be input.
> I'd say both for symmetry.
>
OK, I see the point. Thanks.
Best,
Wei
^ permalink raw reply
* Re: [PATCH] mm: don't zero ballooned pages
From: Michal Hocko @ 2017-07-31 8:37 UTC (permalink / raw)
To: ZhenweiPi
Cc: mst, mawilcox, dave.hansen, linux-kernel, virtualization,
linux-mm, akpm
In-Reply-To: <32d9c53d-5310-25a7-0348-a6cf362a5dcd@youruncloud.com>
On Mon 31-07-17 16:23:26, ZhenweiPi wrote:
> On 07/31/2017 03:51 PM, Michal Hocko wrote:
>
> >On Mon 31-07-17 15:41:49, Wei Wang wrote:
> >>>On 07/31/2017 02:55 PM, Michal Hocko wrote:
> >>>> >On Mon 31-07-17 12:13:33, Wei Wang wrote:
> >>>>> >>Ballooned pages will be marked as MADV_DONTNEED by the hypervisor and
> >>>>> >>shouldn't be given to the host ksmd to scan.
> >>>> >Could you point me where this MADV_DONTNEED is done, please?
> >>>
> >>>Sure. It's done in the hypervisor when the balloon pages are received.
> >>>
> >>>Please see line 40 at
> >>>https://github.com/qemu/qemu/blob/master/hw/virtio/virtio-balloon.c
> >And one more thing. I am not familiar with ksm much. But how is
> >MADV_DONTNEED even helping? This madvise is not sticky - aka it will
> >unmap the range without leaving any note behind. AFAICS the only way
> >to have vma scanned is to have VM_MERGEABLE and that is an opt in:
> >See Documentation/vm/ksm.txt
> >"
> >KSM only operates on those areas of address space which an application
> >has advised to be likely candidates for merging, by using the madvise(2)
> >system call: int madvise(addr, length, MADV_MERGEABLE).
> >"
> >
> >So what exactly is going on here? The original patch looks highly
> >suspicious as well. If somebody wants to make that memory mergable then
> >the user of that memory should zero them out.
>
> Kernel starts a kthread named "ksmd". ksmd scans the VM_MERGEABLE
> memory, and merge the same pages.(same page means memcmp(page1,
> page2, PAGESIZE) == 0).
>
> Guest can not use ballooned pages, and these pages will not be accessed
> in a long time. Kswapd on host will swap these pages out and get more
> free memory.
>
> Rather than swapping, KSM has better performence. Presently pages in
> the balloon device have random value, they usually cannot be merged.
> So enqueue zero pages will resolve this problem.
>
> Because MADV_DONTNEED depends on host os capability and hypervisor capability,
> I prefer to enqueue zero pages to balloon device and made this patch.
So why exactly are we zeroying pages (and pay some cost for that) in
guest when we do not know what host actually does with them?
--
Michal Hocko
SUSE Labs
^ permalink raw reply
* Re: [PATCH] mm: don't zero ballooned pages
From: Wei Wang @ 2017-07-31 8:34 UTC (permalink / raw)
To: Michal Hocko
Cc: mst, mawilcox, dave.hansen, linux-kernel, virtualization,
linux-mm, akpm, zhenwei.pi
In-Reply-To: <20170731074350.GC15767@dhcp22.suse.cz>
On 07/31/2017 03:43 PM, Michal Hocko wrote:
> On Mon 31-07-17 15:41:49, Wei Wang wrote:
>> On 07/31/2017 02:55 PM, Michal Hocko wrote:
>>> On Mon 31-07-17 12:13:33, Wei Wang wrote:
>>>> Ballooned pages will be marked as MADV_DONTNEED by the hypervisor and
>>>> shouldn't be given to the host ksmd to scan.
>>> Could you point me where this MADV_DONTNEED is done, please?
>> Sure. It's done in the hypervisor when the balloon pages are received.
>>
>> Please see line 40 at
>> https://github.com/qemu/qemu/blob/master/hw/virtio/virtio-balloon.c
> Thanks. Are all hypervisors which are using this API doing this?
The implementation may be different across different hypervisors.
But the underlying concept is the same - they unmap the balloon
pages from the guest and those pages will be given to other guests
or host processes to use.
Regardless of the implementation, I think it is an improper operation
to make the memory KSM mergeable when the memory does not
belong to the guest anymore.
Best,
Wei
^ permalink raw reply
* Re: [PATCH] mm: don't zero ballooned pages
From: ZhenweiPi @ 2017-07-31 8:23 UTC (permalink / raw)
To: Michal Hocko, Wei Wang
Cc: mst, mawilcox, dave.hansen, linux-kernel, virtualization,
linux-mm, akpm
In-Reply-To: <20170731075153.GD15767@dhcp22.suse.cz>
[-- Attachment #1.1: Type: text/plain, Size: 1942 bytes --]
On 07/31/2017 03:51 PM, Michal Hocko wrote:
> On Mon 31-07-17 15:41:49, Wei Wang wrote:
>> >On 07/31/2017 02:55 PM, Michal Hocko wrote:
>>> > >On Mon 31-07-17 12:13:33, Wei Wang wrote:
>>>> > >>Ballooned pages will be marked as MADV_DONTNEED by the hypervisor and
>>>> > >>shouldn't be given to the host ksmd to scan.
>>> > >Could you point me where this MADV_DONTNEED is done, please?
>> >
>> >Sure. It's done in the hypervisor when the balloon pages are received.
>> >
>> >Please see line 40 at
>> >https://github.com/qemu/qemu/blob/master/hw/virtio/virtio-balloon.c
> And one more thing. I am not familiar with ksm much. But how is
> MADV_DONTNEED even helping? This madvise is not sticky - aka it will
> unmap the range without leaving any note behind. AFAICS the only way
> to have vma scanned is to have VM_MERGEABLE and that is an opt in:
> See Documentation/vm/ksm.txt
> "
> KSM only operates on those areas of address space which an application
> has advised to be likely candidates for merging, by using the madvise(2)
> system call: int madvise(addr, length, MADV_MERGEABLE).
> "
>
> So what exactly is going on here? The original patch looks highly
> suspicious as well. If somebody wants to make that memory mergable then
> the user of that memory should zero them out.
Kernel starts a kthread named "ksmd". ksmd scans the VM_MERGEABLE
memory, and merge the same pages.(same page means memcmp(page1,
page2, PAGESIZE) == 0).
Guest can not use ballooned pages, and these pages will not be accessed
in a long time. Kswapd on host will swap these pages out and get more
free memory.
Rather than swapping, KSM has better performence. Presently pages in
the balloon device have random value, they usually cannot be merged.
So enqueue zero pages will resolve this problem.
Because MADV_DONTNEED depends on host os capability and hypervisor capability,
I prefer to enqueue zero pages to balloon device and made this patch.
[-- Attachment #1.2: Type: text/html, Size: 3318 bytes --]
[-- Attachment #2: Type: text/plain, Size: 183 bytes --]
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [PATCH] mm: don't zero ballooned pages
From: Michal Hocko @ 2017-07-31 7:51 UTC (permalink / raw)
To: Wei Wang
Cc: mst, mawilcox, dave.hansen, linux-kernel, virtualization,
linux-mm, akpm, zhenwei.pi
In-Reply-To: <597EDF3D.8020101@intel.com>
On Mon 31-07-17 15:41:49, Wei Wang wrote:
> On 07/31/2017 02:55 PM, Michal Hocko wrote:
> >On Mon 31-07-17 12:13:33, Wei Wang wrote:
> >>Ballooned pages will be marked as MADV_DONTNEED by the hypervisor and
> >>shouldn't be given to the host ksmd to scan.
> >Could you point me where this MADV_DONTNEED is done, please?
>
> Sure. It's done in the hypervisor when the balloon pages are received.
>
> Please see line 40 at
> https://github.com/qemu/qemu/blob/master/hw/virtio/virtio-balloon.c
And one more thing. I am not familiar with ksm much. But how is
MADV_DONTNEED even helping? This madvise is not sticky - aka it will
unmap the range without leaving any note behind. AFAICS the only way
to have vma scanned is to have VM_MERGEABLE and that is an opt in:
See Documentation/vm/ksm.txt
"
KSM only operates on those areas of address space which an application
has advised to be likely candidates for merging, by using the madvise(2)
system call: int madvise(addr, length, MADV_MERGEABLE).
"
So what exactly is going on here? The original patch looks highly
suspicious as well. If somebody wants to make that memory mergable then
the user of that memory should zero them out.
--
Michal Hocko
SUSE Labs
^ permalink raw reply
* Re: [PATCH] mm: don't zero ballooned pages
From: Michal Hocko @ 2017-07-31 7:43 UTC (permalink / raw)
To: Wei Wang
Cc: mst, mawilcox, dave.hansen, linux-kernel, virtualization,
linux-mm, akpm, zhenwei.pi
In-Reply-To: <597EDF3D.8020101@intel.com>
On Mon 31-07-17 15:41:49, Wei Wang wrote:
> On 07/31/2017 02:55 PM, Michal Hocko wrote:
> >On Mon 31-07-17 12:13:33, Wei Wang wrote:
> >>Ballooned pages will be marked as MADV_DONTNEED by the hypervisor and
> >>shouldn't be given to the host ksmd to scan.
> >Could you point me where this MADV_DONTNEED is done, please?
>
> Sure. It's done in the hypervisor when the balloon pages are received.
>
> Please see line 40 at
> https://github.com/qemu/qemu/blob/master/hw/virtio/virtio-balloon.c
Thanks. Are all hypervisors which are using this API doing this?
bb01b64cfab7 doesn't mention the specify hypervisor nor does it mention
any real numbers so I suspect the revert is the right thing to do but
the changelog should mention all those details.
--
Michal Hocko
SUSE Labs
^ permalink raw reply
* Re: [PATCH] mm: don't zero ballooned pages
From: Wei Wang @ 2017-07-31 7:41 UTC (permalink / raw)
To: Michal Hocko
Cc: mst, mawilcox, dave.hansen, linux-kernel, virtualization,
linux-mm, akpm, zhenwei.pi
In-Reply-To: <20170731065508.GE13036@dhcp22.suse.cz>
On 07/31/2017 02:55 PM, Michal Hocko wrote:
> On Mon 31-07-17 12:13:33, Wei Wang wrote:
>> Ballooned pages will be marked as MADV_DONTNEED by the hypervisor and
>> shouldn't be given to the host ksmd to scan.
> Could you point me where this MADV_DONTNEED is done, please?
Sure. It's done in the hypervisor when the balloon pages are received.
Please see line 40 at
https://github.com/qemu/qemu/blob/master/hw/virtio/virtio-balloon.c
>
>> Therefore, it is not
>> necessary to zero ballooned pages, which is very time consuming when
>> the page amount is large. The ongoing fast balloon tests show that the
>> time to balloon 7G pages is increased from ~491ms to 2.8 seconds with
>> __GFP_ZERO added. So, this patch removes the flag.
> Please make it obvious that this is a revert of bb01b64cfab7
> ("mm/balloon_compaction.c: enqueue zero page to balloon device").
>
>
Ok, will do.
Best,
Wei
^ permalink raw reply
* Re: [PATCH] mm: don't zero ballooned pages
From: ZhenweiPi @ 2017-07-31 7:39 UTC (permalink / raw)
To: Michal Hocko, Wei Wang
Cc: mst, mawilcox, dave.hansen, linux-kernel, virtualization,
linux-mm, akpm
In-Reply-To: <20170731065508.GE13036@dhcp22.suse.cz>
on qemu upstream, code in qemu/util/osdep.c
int qemu_madvise(void *addr, size_t len, int advice)
{
if (advice == QEMU_MADV_INVALID) {
errno = EINVAL;
return -1;
}
#if defined(CONFIG_MADVISE)
return madvise(addr, len, advice);
#elif defined(CONFIG_POSIX_MADVISE)
return posix_madvise(addr, len, advice);
#else
errno = EINVAL;
return -1;
#endif
}
Host OS maybe not support MADV_DONTNEED.
And madvise syscall uses more time.
On 07/31/2017 02:55 PM, Michal Hocko wrote:
> On Mon 31-07-17 12:13:33, Wei Wang wrote:
>> Ballooned pages will be marked as MADV_DONTNEED by the hypervisor and
>> shouldn't be given to the host ksmd to scan.
> Could you point me where this MADV_DONTNEED is done, please?
>
>> Therefore, it is not
>> necessary to zero ballooned pages, which is very time consuming when
>> the page amount is large. The ongoing fast balloon tests show that the
>> time to balloon 7G pages is increased from ~491ms to 2.8 seconds with
>> __GFP_ZERO added. So, this patch removes the flag.
> Please make it obvious that this is a revert of bb01b64cfab7
> ("mm/balloon_compaction.c: enqueue zero page to balloon device").
>
>> Signed-off-by: Wei Wang <wei.w.wang@intel.com>
>> ---
>> mm/balloon_compaction.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/mm/balloon_compaction.c b/mm/balloon_compaction.c
>> index 9075aa5..b06d9fe 100644
>> --- a/mm/balloon_compaction.c
>> +++ b/mm/balloon_compaction.c
>> @@ -24,7 +24,7 @@ struct page *balloon_page_enqueue(struct balloon_dev_info *b_dev_info)
>> {
>> unsigned long flags;
>> struct page *page = alloc_page(balloon_mapping_gfp_mask() |
>> - __GFP_NOMEMALLOC | __GFP_NORETRY | __GFP_ZERO);
>> + __GFP_NOMEMALLOC | __GFP_NORETRY);
>> if (!page)
>> return NULL;
>>
>> --
>> 2.7.4
>>
^ permalink raw reply
* Re: [PATCH] mm: don't zero ballooned pages
From: Michal Hocko @ 2017-07-31 6:55 UTC (permalink / raw)
To: Wei Wang
Cc: mst, mawilcox, dave.hansen, linux-kernel, virtualization,
linux-mm, akpm, zhenwei.pi
In-Reply-To: <1501474413-21580-1-git-send-email-wei.w.wang@intel.com>
On Mon 31-07-17 12:13:33, Wei Wang wrote:
> Ballooned pages will be marked as MADV_DONTNEED by the hypervisor and
> shouldn't be given to the host ksmd to scan.
Could you point me where this MADV_DONTNEED is done, please?
> Therefore, it is not
> necessary to zero ballooned pages, which is very time consuming when
> the page amount is large. The ongoing fast balloon tests show that the
> time to balloon 7G pages is increased from ~491ms to 2.8 seconds with
> __GFP_ZERO added. So, this patch removes the flag.
Please make it obvious that this is a revert of bb01b64cfab7
("mm/balloon_compaction.c: enqueue zero page to balloon device").
> Signed-off-by: Wei Wang <wei.w.wang@intel.com>
> ---
> mm/balloon_compaction.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/mm/balloon_compaction.c b/mm/balloon_compaction.c
> index 9075aa5..b06d9fe 100644
> --- a/mm/balloon_compaction.c
> +++ b/mm/balloon_compaction.c
> @@ -24,7 +24,7 @@ struct page *balloon_page_enqueue(struct balloon_dev_info *b_dev_info)
> {
> unsigned long flags;
> struct page *page = alloc_page(balloon_mapping_gfp_mask() |
> - __GFP_NOMEMALLOC | __GFP_NORETRY | __GFP_ZERO);
> + __GFP_NOMEMALLOC | __GFP_NORETRY);
> if (!page)
> return NULL;
>
> --
> 2.7.4
>
--
Michal Hocko
SUSE Labs
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox