lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 9 Nov 2017 14:16:12 +0100
From:   Michal Hocko <mhocko@...nel.org>
To:     Vitaly Kuznetsov <vkuznets@...hat.com>
Cc:     linux-mm@...ck.org, linux-kernel@...r.kernel.org,
        Andrew Morton <akpm@...ux-foundation.org>,
        Vlastimil Babka <vbabka@...e.cz>,
        Mel Gorman <mgorman@...hsingularity.net>,
        YASUAKI ISHIMATSU <yasu.isimatu@...il.com>,
        Hillf Danton <hillf.zj@...baba-inc.com>,
        Johannes Weiner <hannes@...xchg.org>,
        "K. Y. Srinivasan" <kys@...rosoft.com>,
        Stephen Hemminger <sthemmin@...rosoft.com>,
        Alex Ng <alexng@...rosoft.com>
Subject: Re: [PATCH RFC] mm/memory_hotplug: make it possible to offline
 blocks with reserved pages

On Wed 08-11-17 17:16:19, Vitaly Kuznetsov wrote:
> Michal Hocko <mhocko@...nel.org> writes:
> 
> > On Wed 08-11-17 16:39:49, Vitaly Kuznetsov wrote:
> >> Michal Hocko <mhocko@...nel.org> writes:
> >> 
> >> > On Wed 08-11-17 14:01:55, Vitaly Kuznetsov wrote:
> >> >> Hyper-V balloon driver needs to hotplug memory in smaller chunks and to
> >> >> workaround Linux's 128Mb allignment requirement so it does a trick: partly
> >> >> populated 128Mb blocks are added and then a custom online_page_callback
> >> >> hook checks if the particular page is 'backed' during onlining, in case it
> >> >> is not backed it is left in Reserved state. When the host adds more pages
> >> >> to the block we bring them online from the driver (see
> >> >> hv_bring_pgs_online()/hv_page_online_one() in drivers/hv/hv_balloon.c).
> >> >> Eventually the whole block becomes fully populated and we hotplug the next
> >> >> 128Mb. This all works for quite some time already.
> >> >
> >> > Why does HyperV needs to workaround the section size limit in the first
> >> > place? We are allocation memmap for the whole section anyway so it won't
> >> > save any memory. So the whole thing sounds rather dubious to me.
> >> >
> >> 
> >> Memory hotplug requirements in Windows are different, they have 2Mb
> >> granularity, not 128Mb like we have in Linux x86.
> >> 
> >> Imagine there's a request to add 32Mb of memory comming from the
> >> Hyper-V host. What can we do? Don't add anything at all and wait till
> >> we're suggested to add > 128Mb and then add a section or the current
> >> approach.
> >
> > Use a different approach than memory hotplug. E.g. memory balloning.
> >
> 
> But how? When we boot we may have very little memory and later on we
> hotplug a lot so we may not even be able to ballon all possible memory
> without running out of memory.

Just add more memory and make part of it unusable and return it back to
the host via standard ballooning means.

How realistic is that the host gives only such a small amount of memory
btw?
-- 
Michal Hocko
SUSE Labs

Powered by blists - more mailing lists