[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <b99ef113-a9c1-f580-0fee-9f258b861391@intel.com>
Date: Wed, 2 Jan 2019 08:47:25 -0800
From: Dave Hansen <dave.hansen@...el.com>
To: Fengguang Wu <fengguang.wu@...el.com>,
Andrew Morton <akpm@...ux-foundation.org>
Cc: Linux Memory Management List <linux-mm@...ck.org>,
Yao Yuan <yuan.yao@...el.com>, kvm@...r.kernel.org,
LKML <linux-kernel@...r.kernel.org>, Fan Du <fan.du@...el.com>,
Peng Dong <dongx.peng@...el.com>,
Huang Ying <ying.huang@...el.com>,
Liu Jingqi <jingqi.liu@...el.com>,
Dong Eddie <eddie.dong@...el.com>,
Zhang Yi <yi.z.zhang@...ux.intel.com>,
Dan Williams <dan.j.williams@...el.com>
Subject: Re: [RFC][PATCH v2 11/21] kvm: allocate page table pages from DRAM
On 12/26/18 5:14 AM, Fengguang Wu wrote:
> +static unsigned long __get_dram_free_pages(gfp_t gfp_mask)
> +{
> + struct page *page;
> +
> + page = __alloc_pages(GFP_KERNEL_ACCOUNT, 0, numa_node_id());
> + if (!page)
> + return 0;
> + return (unsigned long) page_address(page);
> +}
There seems to be a ton of *policy* baked into these patches. For
instance: thou shalt not allocate page tables pages from PMEM. That's
surely not a policy we want to inflict on every Linux user until the end
of time.
I think the more important question is how we can have the specific
policy that this patch implements, but also leave open room for other
policies, such as: "I don't care how slow this VM runs, minimize the
amount of fast memory it eats."
Powered by blists - more mailing lists