From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jonathan Corbet 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 Message-ID: <20170921061631.2afa4e40@lwn.net> References: <29c2bb7e-8299-4942-8189-a8914c7c03aa.ljy@baibantech.com.cn> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Cc: "kvm" , "linux-kernel" , "Jan Kiszka" , " =?UTF-8?B?5p2o5rO95piV?=" , "=?UTF-8?B?546L5paM?=" , "=?UTF-8?B?5p2O54+F?=" To: "XaviLi" Return-path: In-Reply-To: <29c2bb7e-8299-4942-8189-a8914c7c03aa.ljy@baibantech.com.cn> Sender: linux-kernel-owner@vger.kernel.org List-Id: kvm.vger.kernel.org On Thu, 21 Sep 2017 16:25:39 +0800 "XaviLi" 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