All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: wei.w.wang@intel.com, virtio-dev@lists.oasis-open.org,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	virtualization <virtualization@lists.linux-foundation.org>,
	KVM list <kvm@vger.kernel.org>, linux-mm <linux-mm@kvack.org>,
	Michal Hocko <mhocko@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Paolo Bonzini <pbonzini@redhat.com>,
	liliang.opensource@gmail.com, yang.zhang.wz@gmail.com,
	quan.xu0@gmail.com, nilal@redhat.com,
	Rik van Riel <riel@redhat.com>,
	peterx@redhat.com
Subject: Re: [PATCH v33 1/4] mm: add a function to get free page blocks
Date: Wed, 27 Jun 2018 22:07:02 +0300	[thread overview]
Message-ID: <20180627220402-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <CA+55aFwFpDPvfL=KPdabO-x1r0FnwpfPk5oN8+e01TKqAPNYbw@mail.gmail.com>

On Wed, Jun 27, 2018 at 09:05:39AM -0700, Linus Torvalds wrote:
> [ Sorry for slow reply, my travels have made a mess of my inbox ]
> 
> On Mon, Jun 25, 2018 at 6:55 PM Michael S. Tsirkin <mst@redhat.com> wrote:
> >
> > Linus, do you think it would be ok to have get_from_free_page_list
> > actually pop entries from the free list and use them as the buffer
> > to store PAs?
> 
> Honestly, what I think the best option would be is to get rid of this
> interface *entirely*, and just have the balloon code do
> 
>     #define GFP_MINFLAGS (__GFP_NORETRY | __GFP_NOWARN |
> __GFP_THISNODE | __GFP_NOMEMALLOC)
> 
>     struct page *page =  alloc_pages(GFP_MINFLAGS, MAX_ORDER-1);
> 
>  which is not a new interface, and simply removes the max-order page
> from the list if at all possible.
> 
> The above has the advantage of "just working", and not having any races.
> 
> Now, because you don't want to necessarily *entirely* deplete the max
> order, I'd suggest that the *one* new interface you add is just a "how
> many max-order pages are there" interface. So then you can query
> (either before or after getting the max-order page) just how many of
> them there were and whether you want to give that page back.
> 
> Notice? No need for any page lists or physical addresses. No races. No
> complex new functions.
> 
> The physical address you can just get from the "struct page" you got.
> 
> And if you run out of memory because of getting a page, you get all
> the usual "hey, we ran out of memory" responses..
> 
> Wouldn't the above be sufficient?
> 
>             Linus

I think so, thanks!

Wei, to put it in balloon terms, I think there's one thing we missed: if
you do manage to allocate a page, and you don't have a use for it, then
hey, you can just give it to the host because you know it's free - you
are going to return it to the free list.

-- 
MST

WARNING: multiple messages have this Message-ID (diff)
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: yang.zhang.wz@gmail.com, virtio-dev@lists.oasis-open.org,
	Rik van Riel <riel@redhat.com>,
	quan.xu0@gmail.com, KVM list <kvm@vger.kernel.org>,
	nilal@redhat.com, liliang.opensource@gmail.com,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	virtualization <virtualization@lists.linux-foundation.org>,
	linux-mm <linux-mm@kvack.org>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Michal Hocko <mhocko@kernel.org>
Subject: Re: [PATCH v33 1/4] mm: add a function to get free page blocks
Date: Wed, 27 Jun 2018 22:07:02 +0300	[thread overview]
Message-ID: <20180627220402-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <CA+55aFwFpDPvfL=KPdabO-x1r0FnwpfPk5oN8+e01TKqAPNYbw@mail.gmail.com>

On Wed, Jun 27, 2018 at 09:05:39AM -0700, Linus Torvalds wrote:
> [ Sorry for slow reply, my travels have made a mess of my inbox ]
> 
> On Mon, Jun 25, 2018 at 6:55 PM Michael S. Tsirkin <mst@redhat.com> wrote:
> >
> > Linus, do you think it would be ok to have get_from_free_page_list
> > actually pop entries from the free list and use them as the buffer
> > to store PAs?
> 
> Honestly, what I think the best option would be is to get rid of this
> interface *entirely*, and just have the balloon code do
> 
>     #define GFP_MINFLAGS (__GFP_NORETRY | __GFP_NOWARN |
> __GFP_THISNODE | __GFP_NOMEMALLOC)
> 
>     struct page *page =  alloc_pages(GFP_MINFLAGS, MAX_ORDER-1);
> 
>  which is not a new interface, and simply removes the max-order page
> from the list if at all possible.
> 
> The above has the advantage of "just working", and not having any races.
> 
> Now, because you don't want to necessarily *entirely* deplete the max
> order, I'd suggest that the *one* new interface you add is just a "how
> many max-order pages are there" interface. So then you can query
> (either before or after getting the max-order page) just how many of
> them there were and whether you want to give that page back.
> 
> Notice? No need for any page lists or physical addresses. No races. No
> complex new functions.
> 
> The physical address you can just get from the "struct page" you got.
> 
> And if you run out of memory because of getting a page, you get all
> the usual "hey, we ran out of memory" responses..
> 
> Wouldn't the above be sufficient?
> 
>             Linus

I think so, thanks!

Wei, to put it in balloon terms, I think there's one thing we missed: if
you do manage to allocate a page, and you don't have a use for it, then
hey, you can just give it to the host because you know it's free - you
are going to return it to the free list.

-- 
MST

WARNING: multiple messages have this Message-ID (diff)
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: wei.w.wang@intel.com, virtio-dev@lists.oasis-open.org,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	virtualization <virtualization@lists.linux-foundation.org>,
	KVM list <kvm@vger.kernel.org>, linux-mm <linux-mm@kvack.org>,
	Michal Hocko <mhocko@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Paolo Bonzini <pbonzini@redhat.com>,
	liliang.opensource@gmail.com, yang.zhang.wz@gmail.com,
	quan.xu0@gmail.com, nilal@redhat.com,
	Rik van Riel <riel@redhat.com>,
	peterx@redhat.com
Subject: [virtio-dev] Re: [PATCH v33 1/4] mm: add a function to get free page blocks
Date: Wed, 27 Jun 2018 22:07:02 +0300	[thread overview]
Message-ID: <20180627220402-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <CA+55aFwFpDPvfL=KPdabO-x1r0FnwpfPk5oN8+e01TKqAPNYbw@mail.gmail.com>

On Wed, Jun 27, 2018 at 09:05:39AM -0700, Linus Torvalds wrote:
> [ Sorry for slow reply, my travels have made a mess of my inbox ]
> 
> On Mon, Jun 25, 2018 at 6:55 PM Michael S. Tsirkin <mst@redhat.com> wrote:
> >
> > Linus, do you think it would be ok to have get_from_free_page_list
> > actually pop entries from the free list and use them as the buffer
> > to store PAs?
> 
> Honestly, what I think the best option would be is to get rid of this
> interface *entirely*, and just have the balloon code do
> 
>     #define GFP_MINFLAGS (__GFP_NORETRY | __GFP_NOWARN |
> __GFP_THISNODE | __GFP_NOMEMALLOC)
> 
>     struct page *page =  alloc_pages(GFP_MINFLAGS, MAX_ORDER-1);
> 
>  which is not a new interface, and simply removes the max-order page
> from the list if at all possible.
> 
> The above has the advantage of "just working", and not having any races.
> 
> Now, because you don't want to necessarily *entirely* deplete the max
> order, I'd suggest that the *one* new interface you add is just a "how
> many max-order pages are there" interface. So then you can query
> (either before or after getting the max-order page) just how many of
> them there were and whether you want to give that page back.
> 
> Notice? No need for any page lists or physical addresses. No races. No
> complex new functions.
> 
> The physical address you can just get from the "struct page" you got.
> 
> And if you run out of memory because of getting a page, you get all
> the usual "hey, we ran out of memory" responses..
> 
> Wouldn't the above be sufficient?
> 
>             Linus

I think so, thanks!

Wei, to put it in balloon terms, I think there's one thing we missed: if
you do manage to allocate a page, and you don't have a use for it, then
hey, you can just give it to the host because you know it's free - you
are going to return it to the free list.

-- 
MST

---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org


  reply	other threads:[~2018-06-27 19:07 UTC|newest]

Thread overview: 99+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-15  4:43 [PATCH v33 0/4] Virtio-balloon: support free page reporting Wei Wang
2018-06-15  4:43 ` [virtio-dev] " Wei Wang
2018-06-15  4:43 ` [PATCH v33 1/4] mm: add a function to get free page blocks Wei Wang
2018-06-15  4:43   ` [virtio-dev] " Wei Wang
2018-06-15 23:08   ` Linus Torvalds
2018-06-15 23:08     ` Linus Torvalds
2018-06-16  1:19     ` Wang, Wei W
2018-06-16  1:19       ` [virtio-dev] " Wang, Wei W
2018-06-16  1:19       ` Wang, Wei W
2018-06-26  1:55     ` Michael S. Tsirkin
2018-06-26  1:55       ` [virtio-dev] " Michael S. Tsirkin
2018-06-26  1:55       ` Michael S. Tsirkin
2018-06-27 16:05       ` Linus Torvalds
2018-06-27 16:05         ` Linus Torvalds
2018-06-27 19:07         ` Michael S. Tsirkin [this message]
2018-06-27 19:07           ` [virtio-dev] " Michael S. Tsirkin
2018-06-27 19:07           ` Michael S. Tsirkin
2018-06-28  8:39           ` Wei Wang
2018-06-28  8:39             ` [virtio-dev] " Wei Wang
2018-06-28  8:39           ` Wei Wang
2018-06-16  4:50   ` Matthew Wilcox
2018-06-16  4:50     ` Matthew Wilcox
2018-06-17  0:07     ` Wang, Wei W
2018-06-17  0:07       ` [virtio-dev] " Wang, Wei W
2018-06-17  0:07       ` Wang, Wei W
2018-06-17  0:07       ` Wang, Wei W
2018-06-18  2:16     ` Michael S. Tsirkin
2018-06-18  2:16       ` [virtio-dev] " Michael S. Tsirkin
2018-06-18  2:16       ` Michael S. Tsirkin
2018-06-15  4:43 ` Wei Wang
2018-06-15  4:43 ` [PATCH v33 2/4] virtio-balloon: VIRTIO_BALLOON_F_FREE_PAGE_HINT Wei Wang
2018-06-15  4:43   ` [virtio-dev] " Wei Wang
2018-06-15 11:42   ` Michael S. Tsirkin
2018-06-15 11:42     ` [virtio-dev] " Michael S. Tsirkin
2018-06-15 11:42     ` Michael S. Tsirkin
2018-06-15 14:11     ` Wang, Wei W
2018-06-15 14:11       ` [virtio-dev] " Wang, Wei W
2018-06-15 14:11       ` Wang, Wei W
2018-06-15 14:11       ` Wang, Wei W
2018-06-15 14:29       ` Michael S. Tsirkin
2018-06-15 14:29         ` [virtio-dev] " Michael S. Tsirkin
2018-06-15 14:29         ` Michael S. Tsirkin
2018-06-15 14:29         ` Michael S. Tsirkin
2018-06-16  1:09         ` Wang, Wei W
2018-06-16  1:09           ` [virtio-dev] " Wang, Wei W
2018-06-16  1:09           ` Wang, Wei W
2018-06-16  1:09           ` Wang, Wei W
2018-06-18  2:28           ` Michael S. Tsirkin
2018-06-18  2:28             ` [virtio-dev] " Michael S. Tsirkin
2018-06-18  2:28             ` Michael S. Tsirkin
2018-06-18  2:28             ` Michael S. Tsirkin
2018-06-19  1:06             ` [virtio-dev] " Wang, Wei W
2018-06-19  1:06               ` Wang, Wei W
2018-06-19  1:06               ` Wang, Wei W
2018-06-19  1:06               ` Wang, Wei W
2018-06-19  3:05               ` [virtio-dev] " Michael S. Tsirkin
2018-06-19  3:05               ` Michael S. Tsirkin
2018-06-19  3:05                 ` Michael S. Tsirkin
2018-06-19  3:05                 ` Michael S. Tsirkin
2018-06-19  3:05                 ` Michael S. Tsirkin
2018-06-19 12:13                 ` Wei Wang
2018-06-19 12:13                   ` Wei Wang
2018-06-19 12:13                   ` Wei Wang
2018-06-19 12:13                   ` Wei Wang
2018-06-19 14:43                   ` Michael S. Tsirkin
2018-06-19 14:43                   ` Michael S. Tsirkin
2018-06-19 14:43                     ` Michael S. Tsirkin
2018-06-19 14:43                     ` Michael S. Tsirkin
2018-06-19 14:43                     ` Michael S. Tsirkin
2018-06-20  9:11                     ` Wang, Wei W
2018-06-20  9:11                       ` Wang, Wei W
2018-06-20  9:11                       ` Wang, Wei W
2018-06-20  9:11                       ` Wang, Wei W
2018-06-20 14:14                       ` Michael S. Tsirkin
2018-06-20 14:14                         ` Michael S. Tsirkin
2018-06-20 14:14                         ` Michael S. Tsirkin
2018-06-20 14:14                         ` Michael S. Tsirkin
2018-06-19  1:06             ` Wang, Wei W
2018-06-15 14:11     ` Wang, Wei W
2018-06-15  4:43 ` Wei Wang
2018-06-15  4:43 ` [PATCH v33 3/4] mm/page_poison: expose page_poisoning_enabled to kernel modules Wei Wang
2018-06-15  4:43   ` [virtio-dev] " Wei Wang
2018-06-15  4:43 ` Wei Wang
2018-06-15  4:43 ` [PATCH v33 4/4] virtio-balloon: VIRTIO_BALLOON_F_PAGE_POISON Wei Wang
2018-06-15  4:43   ` [virtio-dev] " Wei Wang
2018-06-15  4:43 ` Wei Wang
2018-06-15 11:29 ` [PATCH v33 0/4] Virtio-balloon: support free page reporting Michael S. Tsirkin
2018-06-15 11:29   ` [virtio-dev] " Michael S. Tsirkin
2018-06-15 14:28   ` Wang, Wei W
2018-06-15 14:28     ` [virtio-dev] " Wang, Wei W
2018-06-15 14:28     ` Wang, Wei W
2018-06-15 14:28     ` Wang, Wei W
2018-06-15 14:38     ` Michael S. Tsirkin
2018-06-15 14:38       ` [virtio-dev] " Michael S. Tsirkin
2018-06-15 14:38       ` Michael S. Tsirkin
2018-06-15 14:38       ` Michael S. Tsirkin
2018-06-15 11:29 ` Michael S. Tsirkin
2018-06-15 19:21 ` Luiz Capitulino
2018-06-15 19:21 ` Luiz Capitulino

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=20180627220402-mutt-send-email-mst@kernel.org \
    --to=mst@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=kvm@vger.kernel.org \
    --cc=liliang.opensource@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@kernel.org \
    --cc=nilal@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peterx@redhat.com \
    --cc=quan.xu0@gmail.com \
    --cc=riel@redhat.com \
    --cc=torvalds@linux-foundation.org \
    --cc=virtio-dev@lists.oasis-open.org \
    --cc=virtualization@lists.linux-foundation.org \
    --cc=wei.w.wang@intel.com \
    --cc=yang.zhang.wz@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.