[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <72f4ddeb-157a-808a-2846-dd9961a9c269@redhat.com>
Date: Tue, 13 Oct 2020 09:27:13 +0200
From: Paolo Bonzini <pbonzini@...hat.com>
To: yulei.kernel@...il.com, akpm@...ux-foundation.org,
naoya.horiguchi@....com, viro@...iv.linux.org.uk
Cc: linux-fsdevel@...r.kernel.org, kvm@...r.kernel.org,
linux-kernel@...r.kernel.org, xiaoguangrong.eric@...il.com,
kernellwp@...il.com, lihaiwei.kernel@...il.com,
Yulei Zhang <yuleixzhang@...cent.com>,
Xiao Guangrong <gloryxiao@...cent.com>
Subject: Re: [PATCH 04/35] dmem: let pat recognize dmem
On 08/10/20 09:53, yulei.kernel@...il.com wrote:
> From: Yulei Zhang <yuleixzhang@...cent.com>
>
> x86 pat uses 'struct page' by only checking if it's system ram,
> however it is not true if dmem is used, let's teach pat to
> recognize this case if it is ram but it is !pfn_valid()
>
> We always use WB for dmem and any attempt to change this
> behavior will be rejected and WARN_ON is triggered
>
> Signed-off-by: Xiao Guangrong <gloryxiao@...cent.com>
> Signed-off-by: Yulei Zhang <yuleixzhang@...cent.com>
Hooks like these will make it very hard to merge this series.
I like the idea of struct page-backed memory, but this is a lot of code
and I wonder if it's worth adding all these complications.
One can already use mem= to remove the "struct page" cost for most of
the host memory, and manage the allocation of the remaining memory in
userspace with /dev/mem. What is the advantage of doing this in the kernel?
Paolo
Powered by blists - more mailing lists