We always poll tx for socket, this is sub optimal since:
- it will be only used when we exceed the sndbuf of the socket.
- since we use two independent polls for tx and vq, this will slightly
increase the waitqueue traversing time and more important, vhost
could not benefit from commit
We don't stop rx polling socket during rx processing, this will lead
unnecessary wakeups from under layer net devices (E.g
sock_def_readable() form tun). Rx will be slowed down in this
way. This patch avoids this by stop polling socket during rx
processing. A small drawback is that this introduces
Hi:
This series tries to optimize vhost_net polling at two points:
- Stop rx polling for reduicng the unnecessary wakeups during
handle_rx().
- Conditonally enable tx polling for reducing the unnecessary
traversing and spinlock touching.
Test shows about 17% improvement on rx pps.
Please
We have allowed migration for only LRU pages until now and it was
enough to make high-order pages. But recently, embedded system(e.g.,
webOS, android) uses lots of non-movable pages(e.g., zram, GPU memory)
so we have seen several reports about troubles of small high-order
allocation. For fixing
Now, VM has a feature to migrate non-lru movable pages so
balloon doesn't need custom migration hooks in migrate.c
and compaction.c. Instead, this patch implements
page->mapping->a_ops->{isolate|migrate|putback} functions.
With that, we could remove hooks for ballooning in general
migration
Recently, I got many reports about perfermance degradation in embedded
system(Android mobile phone, webOS TV and so on) and easy fork fail.
The problem was fragmentation caused by zram and GPU driver mainly.
With memory pressure, their pages were spread out all of pageblock and
it cannot be
On Tue, May 31, 2016 at 09:52:48AM +0200, Vlastimil Babka wrote:
> On 05/31/2016 02:01 AM, Minchan Kim wrote:
> >Per Vlastimi's review comment.
> >
> >Thanks for the detail review, Vlastimi!
> >If you have another concern, feel free to say.
>
> I don't for now :)
>
> [...]
>
> >Cc: Rik van Riel
On Tue, 31 May 2016 08:29:20 +0200
Gerd Hoffmann wrote:
> Hi,
>
> > > Why attach the hotspot to the plane? Wouldn't it make more sense to
> > > make it a framebuffer property?
> >
> > We don't have properties on the framebuffer. I guess you /could/ just add
> > it
Pick up the correct source rectangle from framebuffer.
Without this multihead setups are not working correctly.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/virtio/virtgpu_plane.c | 31 ++-
1 file changed, 18 insertions(+), 13 deletions(-)
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/virtio/virtgpu_plane.c | 20 +---
1 file changed, 13 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_plane.c
b/drivers/gpu/drm/virtio/virtgpu_plane.c
index 4780354..b7778a7 100644
---
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/virtio/virtgpu_display.c | 102 --
drivers/gpu/drm/virtio/virtgpu_drv.h | 1 +
drivers/gpu/drm/virtio/virtgpu_plane.c | 105 ---
3 files changed, 109 insertions(+),
Do modesets first, then call drm_atomic_helper_commit_planes with
active_only = true. That way the outputs doesn't get disabled
temporarly on atomic commits.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/virtio/virtgpu_display.c | 22 +-
Needed for multihead setups where we can have disabled
outputs and therefore plane->crtc can be NULL.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/virtio/virtgpu_plane.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git
On 05/31/2016 02:01 AM, Minchan Kim wrote:
Per Vlastimi's review comment.
Thanks for the detail review, Vlastimi!
If you have another concern, feel free to say.
I don't for now :)
[...]
Cc: Rik van Riel
Cc: Vlastimil Babka
Cc: Joonsoo Kim
On 05/30/2016 06:25 PM, Minchan Kim wrote:
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -81,6 +81,39 @@ static inline bool migrate_async_suitable(int migratetype)
#ifdef CONFIG_COMPACTION
+int PageMovable(struct page *page)
+{
+ struct address_space *mapping;
+
+
On Tue, May 31, 2016 at 9:34 AM, Gerd Hoffmann wrote:
> Hi,
>
>> > Right now the virtual outputs are linked to drm_crtc. To apply any
>> > changes I need to lookup the crtc to figure which virtual output should
>> > be updated.
>
>> > So, setting active_only should make sure
Hi,
> > Right now the virtual outputs are linked to drm_crtc. To apply any
> > changes I need to lookup the crtc to figure which virtual output should
> > be updated.
> > So, setting active_only should make sure I have a valid crtc pointer on
> > plane updates, right? It probably also skips
On Mon, May 30, 2016 at 02:03:26PM +0200, Gerd Hoffmann wrote:
> Needed for multihead setups where we can have disabled
> outputs and therefore plane->crtc can be NULL.
>
> Signed-off-by: Gerd Hoffmann
Applied to drm-misc, thanks.
-Daniel
> ---
>
On Tue, May 31, 2016 at 8:29 AM, Gerd Hoffmann wrote:
>> but it also means that
>> atomic userspace can't use hotspots before we add properties to fbs. And
>> doing that is a bit tricky since drm_framebuffer objects are meant to be
>> invariant - this assumption is deeply
On Tue, May 31, 2016 at 8:18 AM, Gerd Hoffmann wrote:
>> > https://lists.freedesktop.org/archives/dri-devel/2016-May/108772.html
>>
>> Hm, smells more like virtio isn't too happy with the default ordering of
>> the commit operation. The default is:
>>
>> - Disable any
Hi,
> > Why attach the hotspot to the plane? Wouldn't it make more sense to
> > make it a framebuffer property?
>
> We don't have properties on the framebuffer. I guess you /could/ just add
> it internally to struct drm_framebuffer, and not bother exposing to
> userspace. I guess that would
Hi,
> > https://lists.freedesktop.org/archives/dri-devel/2016-May/108772.html
>
> Hm, smells more like virtio isn't too happy with the default ordering of
> the commit operation. The default is:
>
> - Disable any crtc/encoders that need to be disabled/change.
> - Bash new plane setup into hw.
22 matches
Mail list logo