From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1751661AbdIUMQe (ORCPT <rfc822;w@1wt.eu>);
        Thu, 21 Sep 2017 08:16:34 -0400
Received: from ms.lwn.net ([45.79.88.28]:55304 "EHLO ms.lwn.net"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1751387AbdIUMQd (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Thu, 21 Sep 2017 08:16:33 -0400
Date: Thu, 21 Sep 2017 06:16:31 -0600
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>,
        " =?UTF-8?B?5p2o5rO95piV?=" <yzx@baibantech.com.cn>,
        "=?UTF-8?B?546L5paM?=" <wb@baibantech.com.cn>,
        "=?UTF-8?B?5p2O54+F?=" <lishen@baibantech.com.cn>
Subject: Re: [RFC] [Resend] Another Para-Virtualization page recycler --
 Code details, Trap-less way to return free pages to kernel
Message-ID: <20170921061631.2afa4e40@lwn.net>
In-Reply-To: <29c2bb7e-8299-4942-8189-a8914c7c03aa.ljy@baibantech.com.cn>
References: <29c2bb7e-8299-4942-8189-a8914c7c03aa.ljy@baibantech.com.cn>
Organization: LWN.net
X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.31; x86_64-redhat-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 8bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

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