Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1736619
| From | Jonathan Corbet <corbet@lwn.net> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [RFC] [Resend] Another Para-Virtualization page recycler -- Code details, Trap-less way to return free pages to kernel |
| Date | 2017-09-21 14:20 +0200 |
| Message-ID | <us8Cu-Sx-23@gated-at.bofh.it> (permalink) |
| References | <us51V-6Qs-31@gated-at.bofh.it> |
| Organization | LWN.net |
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
Back to linux.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread
[RFC] [Resend] Another Para-Virtualization page recycler -- Code details, Trap-less way to return free pages to kernel "XaviLi" <ljy@baibantech.com.cn> - 2017-09-21 10:30 +0200 Re: [RFC] [Resend] Another Para-Virtualization page recycler -- Code details, Trap-less way to return free pages to kernel Jonathan Corbet <corbet@lwn.net> - 2017-09-21 14:20 +0200
csiph-web