DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :cc:content-type;
        b=Zp4ZfdM2iOoS68M7WML8PxhrcUi5r1LuJpvDRzaQXBtDe0KUGHhKrhqxm/FVkS+xpK
         fMnICkB/gqUyBRZZhfQ6iJWG4Hhdx6LzEC+TB401Q82gcpR4Ttxstn9uTna8xlWBlqVM
         ctTVYgPq8U1O+xISOj0WYkh23D3HeOwtrT3SY=
MIME-Version: 1.0
In-Reply-To: <alpine.LSU.2.00.0912301653200.4532@sister.anvils>
References: <20091228115315.76b1ecd0.minchan.kim@barrios-desktop>
	 <4B38246C.3020209@redhat.com>
	 <20091228130926.6874d7b2.minchan.kim@barrios-desktop>
	 <alpine.LSU.2.00.0912301653200.4532@sister.anvils>
Date: Thu, 31 Dec 2009 11:26:36 +0900
Message-ID: <28c262360912301826r36e8a6c3ub6b6f341fbc9db71@mail.gmail.com>
Subject: Re: [PATCH -mmotm-2009-12-10-17-19] Prevent churning of zero page in 
	LRU list.
From: Minchan Kim <minchan.kim@gmail.com>
To: Hugh Dickins <hugh.dickins@tiscali.co.uk>
Cc: Rik van Riel <riel@redhat.com>, Andrew Morton <akpm@linux-foundation.org>,
       lkml <linux-kernel@vger.kernel.org>, linux-mm <linux-mm@kvack.org>,
       KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Content-Type: text/plain; charset=UTF-8
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 3404
Lines: 92

Hi, Hugh.

On Thu, Dec 31, 2009 at 2:03 AM, Hugh Dickins
<hugh.dickins@tiscali.co.uk> wrote:
> On Mon, 28 Dec 2009, Minchan Kim wrote:
>> On Sun, 27 Dec 2009 22:22:20 -0500
>> Rik van Riel <riel@redhat.com> wrote:
>> > On 12/27/2009 09:53 PM, Minchan Kim wrote:
>> > >
>> > > VM doesn't add zero page to LRU list.
>> > > It means zero page's churning in LRU list is pointless.
>> > >
>> > > As a matter of fact, zero page can't be promoted by mark_page_accessed
>> > > since it doesn't have PG_lru.
>> > >
>> > > This patch prevent unecessary mark_page_accessed call of zero page
>> > > alghouth caller want FOLL_TOUCH.
>> > >
>> > > Signed-off-by: Minchan Kim<minchan.kim@gmail.com>
>> >
>> > The code looks correct, but I wonder how frequently we run into
>> > the zero page in this code, vs. how much the added cost is of
>> > having this extra code in follow_page.
>> >
>> > What kind of problem were you running into that motivated you
>> > to write this patch?
>>
>> I didn't have experienced any problem in this case.
>> In fact, I found that while trying to make patch smap_pte_change.
>>
>> Long time ago when we have a zero page, we regards it to file_rss.
>> So while we see the smaps, vm_normal_page returns zero page and we can
>> calculate it properly with PSS.
>>
>> But now we don't acccout zero page to file_rss.
>> I am not sure we have to account it with file_rss.
>> So I think now smaps_pte_range's resident count routine also is changed.
>>
>> Anyway, I think my patch doesn't have much cost since many customers of
>> follow_page are already not a fast path.
>>
>> I tend to agree with your opinion "How frequently we runt into the zero page?"
>> But my thought GUP is export function which can be used for anything by anyone.
>>
>> Thanks for the review, Rik.
>
> I'm guessing that you've now dropped the idea of this patch,
> since it wasn't included along with your 1/3, 2/3, 3/3.
> You thought the ZERO_PAGE was moving around the LRUs, but now
> realize that it isn't, so accept there's no need for this patch?

I mentioned zero page was not moving around the LRU in changelog.
The concern was just unecessary call of mark_page_accessed in zero page.

>
> There's lots of places where we could shave a little time off dealing
> with the ZERO_PAGE by adding tests for it; but at the expense of
> adding code to normal paths of the system, slowing them down.

Indeed. If it is only one  to check, I might insist on this with
performance check.
But if we have many palce to check, this case-by-case approach is a not good.

>
> If there's a proven reason for doing so somewhere, yes, we should
> add such tests to avoid significant cacheline bouncing; but without
> good reason, we just let ZERO_PAGEs fall through the code as they do.
>
> I believe that get_user_pages() on ZERO_PAGEs is exceptional, beyond
> the cases of coredumping and mlock and make_pages_present; but if
> you've evidence for adding a test somewhere, please provide it.

Okay. Because you and Rik who have many experience in real workload
dislike it and
I have no number, I will drop this.

Thanks for all reviewers.

>
> Hugh
>


-- 
Kind regards,
Minchan Kim
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/