[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20191213201556.GC26990@char.us.oracle.com>
Date: Fri, 13 Dec 2019 12:15:56 -0800 (PST)
From: Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
To: David Hildenbrand <david@...hat.com>
Cc: linux-kernel@...r.kernel.org, linux-mm@...ck.org,
virtio-dev@...ts.oasis-open.org,
virtualization@...ts.linux-foundation.org, kvm@...r.kernel.org,
Michal Hocko <mhocko@...nel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
"Michael S . Tsirkin" <mst@...hat.com>,
Sebastien Boeuf <sebastien.boeuf@...el.com>,
Samuel Ortiz <samuel.ortiz@...el.com>,
Robert Bradford <robert.bradford@...el.com>,
Luiz Capitulino <lcapitulino@...hat.com>,
Alexander Duyck <alexander.h.duyck@...ux.intel.com>,
Alexander Potapenko <glider@...gle.com>,
Alexander Viro <viro@...iv.linux.org.uk>,
Anshuman Khandual <anshuman.khandual@....com>,
Anthony Yznaga <anthony.yznaga@...cle.com>,
Dan Williams <dan.j.williams@...el.com>,
Dave Young <dyoung@...hat.com>,
Igor Mammedov <imammedo@...hat.com>,
Jason Wang <jasowang@...hat.com>,
Johannes Weiner <hannes@...xchg.org>,
Juergen Gross <jgross@...e.com>, Len Brown <lenb@...nel.org>,
Mel Gorman <mgorman@...hsingularity.net>,
Michal Hocko <mhocko@...e.com>,
Mike Rapoport <rppt@...ux.ibm.com>,
Oscar Salvador <osalvador@...e.com>,
Oscar Salvador <osalvador@...e.de>,
Pavel Tatashin <pasha.tatashin@...een.com>,
Pavel Tatashin <pavel.tatashin@...rosoft.com>,
Pingfan Liu <kernelfans@...il.com>, Qian Cai <cai@....pw>,
"Rafael J. Wysocki" <rjw@...ysocki.net>,
Stefan Hajnoczi <stefanha@...hat.com>,
Vlastimil Babka <vbabka@...e.cz>,
Wei Yang <richard.weiyang@...il.com>
Subject: Re: [PATCH RFC v4 00/13] virtio-mem: paravirtualized memory
On Thu, Dec 12, 2019 at 06:11:24PM +0100, David Hildenbrand wrote:
> This series is based on latest linux-next. The patches are located at:
> https://github.com/davidhildenbrand/linux.git virtio-mem-rfc-v4
Heya!
Would there be by any chance a virtio-spec git tree somewhere?
..snip..
> --------------------------------------------------------------------------
> 5. Future work
> --------------------------------------------------------------------------
>
> The separate patches contain a lot of future work items. One of the next
> steps is to make memory unplug more likely to succeed - currently, there
> are no guarantees on how much memory can get unplugged again. I have
Or perhaps tell the caller why we can't and let them sort it out?
For example: "Application XYZ is mlocked. Can't offload'.
Powered by blists - more mailing lists