From: Jonathan Corbet <corbet@lwn.net>
To: "XaviLi" <ljy@baibantech.com.cn>
Cc: kvm <kvm@vger.kernel.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
"Jan Kiszka" <jan.kiszka@siemens.com>,
" 杨泽昕" <yzx@baibantech.com.cn>, 王斌 <wb@baibantech.com.cn>,
李珅 <lishen@baibantech.com.cn>
Subject: Re: [RFC] [Resend] Another Para-Virtualization page recycler -- Code details, Trap-less way to return free pages to kernel
Date: Thu, 21 Sep 2017 06:16:31 -0600 [thread overview]
Message-ID: <20170921061631.2afa4e40@lwn.net> (raw)
In-Reply-To: <29c2bb7e-8299-4942-8189-a8914c7c03aa.ljy@baibantech.com.cn>
On Thu, 21 Sep 2017 16:25:39 +0800
"XaviLi" <ljy@baibantech.com.cn> wrote:
> We raised a topic about PPR (Per Page Recycler) and thank to Jan Kiszka
> for advises. We are here to break up patch codes and explain the code
> in detail. There are too many things to explain in one topic. We would
> like to do it part by part. Content of original mails and patches can
> be found below in the end.
If you want these patches to be reviewed, you really need to submit a
proper patch series. Please look at
Documentation/process/submitting-patches.rst for all the details.
You will also want to make the code compliant with the kernel's coding
style.
I have not reviewed this code (nor am I really the person to do a proper
review), but this jumped at me:
> while(mark->desc != 0)
> {
> barrier();
> }
Busy waits in the memory-management code are going to raise a lot of
eyebrows, and you really need to document what you think that barrier()
call is doing. I suspect it's not giving you the protection you think it
is.
jon
next prev parent reply other threads:[~2017-09-21 12:16 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-21 8:25 [RFC] [Resend] Another Para-Virtualization page recycler -- Code details, Trap-less way to return free pages to kernel XaviLi
2017-09-21 12:16 ` Jonathan Corbet [this message]
2017-09-22 8:33 ` XaviLi
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=20170921061631.2afa4e40@lwn.net \
--to=corbet@lwn.net \
--cc=jan.kiszka@siemens.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lishen@baibantech.com.cn \
--cc=ljy@baibantech.com.cn \
--cc=wb@baibantech.com.cn \
--cc=yzx@baibantech.com.cn \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox