From: Nitesh Narayan Lal <nilal@redhat.com>
To: Wei Wang <wei.w.wang@intel.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
"Michael S. Tsirkin" <mst@redhat.com>
Cc: KVM list <kvm@vger.kernel.org>,
virtualization <virtualization@lists.linux-foundation.org>,
Network Development <netdev@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Bjorn Andersson <bjorn.andersson@linaro.org>
Subject: Re: [PULL] vhost: cleanups and fixes
Date: Thu, 14 Jun 2018 11:01:59 -0400 [thread overview]
Message-ID: <0f18063c-c76b-4728-5145-810f069988ea@redhat.com> (raw)
In-Reply-To: <5B1FA8EF.4030409@intel.com>
[-- Attachment #1.1: Type: text/plain, Size: 3316 bytes --]
Hi Wei,
On 06/12/2018 07:05 AM, Wei Wang wrote:
> On 06/12/2018 09:59 AM, Linus Torvalds wrote:
>> On Mon, Jun 11, 2018 at 6:36 PM Michael S. Tsirkin <mst@redhat.com>
>> wrote:
>>> Maybe it will help to have GFP_NONE which will make any allocation
>>> fail if attempted. Linus, would this address your comment?
>> It would definitely have helped me initially overlook that call chain.
>>
>> But then when I started looking at the whole dma_map_page() thing, it
>> just raised my hackles again.
>>
>> I would seriously suggest having a much simpler version for the "no
>> allocation, no dma mapping" case, so that it's *obvious* that that
>> never happens.
>>
>> So instead of having virtio_balloon_send_free_pages() call a really
>> generic complex chain of functions that in _some_ cases can do memory
>> allocation, why isn't there a short-circuited "vitruque_add_datum()"
>> that is guaranteed to never do anything like that?
>>
>> Honestly, I look at "add_one_sg()" and it really doesn't make me
>> happy. It looks hacky as hell. If I read the code right, you're really
>> trying to just queue up a simple tuple of <pfn,len>, except you encode
>> it as a page pointer in order to play games with the SG logic, and
>> then you hmap that to the ring, except in this case it's all a fake
>> ring that just adds the cpu-physical address instead.
>>
>> And to figuer that out, it's like five layers of indirection through
>> different helper functions that *can* do more generic things but in
>> this case don't.
>>
>> And you do all of this from a core VM callback function with some
>> _really_ core VM locks held.
>>
>> That makes no sense to me.
>>
>> How about this:
>>
>> - get rid of all that code
>>
>> - make the core VM callback save the "these are the free memory
>> regions" in a fixed and limited array. One that DOES JUST THAT. No
>> crazy "SG IO dma-mapping function crap". Just a plain array of a fixed
>> size, pre-allocated for that virtio instance.
>>
>> - make it obvious that what you do in that sequence is ten
>> instructions and no allocations ("Look ma, I wrote a value to an array
>> and incremented the array idex, and I'M DONE")
>>
>> - then in that workqueue entry that you start *anyway*, you empty the
>> array and do all the crazy virtio stuff.
>>
>> In fact, while at it, just simplify the VM interface too. Instead of
>> traversing a random number of buddy lists, just trraverse *one* - the
>> top-level one. Are you seriously ever going to shrink or mark
>> read-only anythin *but* something big enough to be in the maximum
>> order?
>>
>> MAX_ORDER is what, 11? So we're talking 8MB blocks. Do you *really*
>> want the balloon code to work on smaller things, particularly since
>> the whole interface is fundamentally racy and opportunistic to begin
>> with?
>
> OK, I will implement a new version based on the suggestions. Thanks.
I have been working on a similar series [1] that is more generic, which
solves the problem of giving unused memory back to the host and could be
used to solve the migration problem as well. Can you take a look and see
if you can use my series in some way?
[1] https://www.spinics.net/lists/kvm/msg170113.html
>
> Best,
> Wei
>
--
Regards
Nitesh
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
next prev parent reply other threads:[~2018-06-14 15:01 UTC|newest]
Thread overview: 65+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-11 16:23 [PULL] vhost: cleanups and fixes Michael S. Tsirkin
2018-06-11 18:32 ` Linus Torvalds
2018-06-11 18:44 ` Linus Torvalds
2018-06-12 1:36 ` Michael S. Tsirkin
2018-06-12 1:59 ` Linus Torvalds
2018-06-12 11:05 ` Wei Wang
2018-06-14 15:01 ` Nitesh Narayan Lal [this message]
2018-06-15 3:53 ` Wei Wang
2018-06-12 1:57 ` Michael S. Tsirkin
[not found] <20200210010252-mutt-send-email-mst@kernel.org>
2020-02-11 2:07 ` Linus Torvalds
-- strict thread matches above, loose matches on Subject: below --
2019-10-15 21:19 Michael S. Tsirkin
2019-10-15 22:25 ` pr-tracker-bot
2019-05-14 21:11 Michael S. Tsirkin
2019-05-14 21:20 ` pr-tracker-bot
2018-11-01 21:19 Michael S. Tsirkin
2018-11-01 21:44 ` Linus Torvalds
2018-11-01 23:00 ` Kees Cook
2018-11-01 23:06 ` Linus Torvalds
2018-11-01 23:55 ` Michael S. Tsirkin
2018-11-02 11:46 ` Mark Rutland
2018-11-02 13:04 ` Michael S. Tsirkin
2018-11-02 16:14 ` Linus Torvalds
2018-11-02 16:59 ` Michael S. Tsirkin
2018-11-02 17:10 ` Linus Torvalds
2018-11-02 17:15 ` Linus Torvalds
2018-11-02 19:01 ` Al Viro
2018-11-02 17:21 ` Michael S. Tsirkin
2018-11-02 18:02 ` Linus Torvalds
2018-11-02 18:12 ` Michael S. Tsirkin
2018-11-30 13:44 ` Michael S. Tsirkin
2018-11-30 19:01 ` Bijan Mottahedeh
2018-11-30 19:55 ` Michael S. Tsirkin
2018-11-01 23:38 ` Michael S. Tsirkin
2017-12-08 15:47 Michael S. Tsirkin
2017-12-04 13:25 Michael S. Tsirkin
2017-08-25 18:47 Michael S. Tsirkin
2017-04-10 21:36 Michael S. Tsirkin
2017-03-02 5:49 Michael S. Tsirkin
2017-02-03 21:43 Michael S. Tsirkin
2017-01-23 15:05 Michael S. Tsirkin
2017-01-23 21:50 ` Linus Torvalds
2017-01-24 2:45 ` Michael S. Tsirkin
2016-05-24 11:57 Michael S. Tsirkin
2015-12-21 7:58 Michael S. Tsirkin
2015-12-07 17:07 Michael S. Tsirkin
2015-09-18 10:42 Michael S. Tsirkin
2015-09-09 9:15 Michael S. Tsirkin
2015-07-28 10:00 Michael S. Tsirkin
2015-07-15 10:50 Michael S. Tsirkin
2015-07-15 11:26 ` Michael S. Tsirkin
2015-06-01 19:18 Michael S. Tsirkin
2015-06-01 19:45 ` Michael S. Tsirkin
2015-01-08 7:51 Michael S. Tsirkin
2015-01-01 12:26 Michael S. Tsirkin
2014-12-18 10:46 Michael S. Tsirkin
2014-11-13 21:22 Michael S. Tsirkin
2014-06-25 11:05 Michael S. Tsirkin
2013-07-15 18:31 Michael S. Tsirkin
2013-07-22 8:07 ` Michael S. Tsirkin
2013-07-08 11:45 Michael S. Tsirkin
2013-05-02 10:53 Michael S. Tsirkin
2013-05-02 18:55 ` Nicholas A. Bellinger
2013-05-02 19:33 ` Michael S. Tsirkin
2013-05-02 19:49 ` Linus Torvalds
2013-06-05 15:53 ` Michael S. Tsirkin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=0f18063c-c76b-4728-5145-810f069988ea@redhat.com \
--to=nilal@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=bjorn.andersson@linaro.org \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mst@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=virtualization@lists.linux-foundation.org \
--cc=wei.w.wang@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).