RE: [PATCH 1/1] mm: Export split_page().

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




> -----Original Message-----
> From: Greg KH [mailto:gregkh@xxxxxxxxxxxxxxxxxxx]
> Sent: Sunday, March 03, 2013 9:25 PM
> To: KY Srinivasan
> Cc: linux-kernel@xxxxxxxxxxxxxxx; devel@xxxxxxxxxxxxxxxxxxxxxx; olaf@xxxxxxxxx;
> apw@xxxxxxxxxxxxx; andi@xxxxxxxxxxxxxx; akpm@xxxxxxxxxxxxxxxxxxxx; linux-
> mm@xxxxxxxxx
> Subject: Re: [PATCH 1/1] mm: Export split_page().
> 
> On Mon, Mar 04, 2013 at 02:14:02AM +0000, KY Srinivasan wrote:
> >
> >
> > > -----Original Message-----
> > > From: Greg KH [mailto:gregkh@xxxxxxxxxxxxxxxxxxx]
> > > Sent: Sunday, March 03, 2013 9:08 PM
> > > To: KY Srinivasan
> > > Cc: linux-kernel@xxxxxxxxxxxxxxx; devel@xxxxxxxxxxxxxxxxxxxxxx;
> olaf@xxxxxxxxx;
> > > apw@xxxxxxxxxxxxx; andi@xxxxxxxxxxxxxx; akpm@xxxxxxxxxxxxxxxxxxxx; linux-
> > > mm@xxxxxxxxx
> > > Subject: Re: [PATCH 1/1] mm: Export split_page().
> > >
> > > On Sun, Mar 03, 2013 at 06:27:55PM -0800, K. Y. Srinivasan wrote:
> > > > The split_page() function will be very useful for balloon drivers. On Hyper-V,
> > > > it will be very efficient to use 2M allocations in the guest as this (a) makes
> > > > the ballooning protocol with the host that much more efficient and (b)
> moving
> > > > memory in 2M chunks minimizes fragmentation in the host. Export the
> > > split_page()
> > > > function to let the guest allocations be in 2M chunks while the host is free to
> > > > return this memory at arbitrary granularity.
> > > >
> > > >
> > > > Signed-off-by: K. Y. Srinivasan <kys@xxxxxxxxxxxxx>
> > > > ---
> > > >  mm/page_alloc.c |    1 +
> > > >  1 files changed, 1 insertions(+), 0 deletions(-)
> > > >
> > > > diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> > > > index 6cacfee..7e0ead6 100644
> > > > --- a/mm/page_alloc.c
> > > > +++ b/mm/page_alloc.c
> > > > @@ -1404,6 +1404,7 @@ void split_page(struct page *page, unsigned int
> order)
> > > >  	for (i = 1; i < (1 << order); i++)
> > > >  		set_page_refcounted(page + i);
> > > >  }
> > > > +EXPORT_SYMBOL_GPL(split_page);
> > >
> > > When you export a symbol, you also need to post the code that is going
> > > to use that symbol, otherwise people don't really know how to judge this
> > > request.
> > >
> > > Can you just make this a part of your balloon driver update patch series
> > > instead?
> >
> > Fair enough; I was hoping to see how inclined the mm folks were with regards
> to
> > exporting this symbol before I went ahead and modified the balloon driver
> code to
> > leverage this. Looking at the Windows guests on Hyper-V, I am convinced 2M
> balloon
> > allocations in the Linux (Hyper-V) balloon driver will make significant difference.
> As you
> > suggest, I will post this patch as part of the balloon driver changes that use this
> exported
> > symbol. I am still hoping to get some feedback from the mm guys on this.
> 
> I guess the most obvious question about exporting this symbol is, "Why
> doesn't any of the other hypervisor balloon drivers need this?  What is
> so special about hyper-v?"

The balloon protocol that Hyper-V has specified is designed around the ability to
move 2M pages. While the protocol can handle 4k allocations, it is going to be very chatty
with 4K allocations. Furthermore, the Memory Balancer on the host is also designed to work
best with memory moving around in 2M chunks. While I have not seen the code on the Windows
host that does this memory balancing, looking at how Windows guests behave in this environment,
(relative to Linux) I have to assume that the 2M allocations that Windows guests do are a big part of
the difference we see.
 
> 
> Or can those other drivers also need/use it as well, and they were just
> too chicken to be asking for the export?  :)

The 2M balloon allocations would make sense if the host is designed accordingly.

Regards,

K. Y


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href


[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]