All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>,
	linux-mm@kvack.org, Andi Kleen <ak@linux.intel.com>,
	"H. Peter Anvin" <hpa@linux.intel.com>,
	linux-kernel@vger.kernel.org,
	"Kirill A. Shutemov" <kirill@shutemov.name>
Subject: Re: [PATCH v5 00/11] Introduce huge zero page
Date: Wed, 14 Nov 2012 13:33:42 -0800	[thread overview]
Message-ID: <20121114133342.cc7bcd6e.akpm@linux-foundation.org> (raw)
In-Reply-To: <1352300463-12627-1-git-send-email-kirill.shutemov@linux.intel.com>

On Wed,  7 Nov 2012 17:00:52 +0200
"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> wrote:

> Andrew, here's updated huge zero page patchset.

There is still a distinct lack of reviewed-by's and acked-by's on this
patchset.

On 13 Sep, Andrea did indicate that he "reviewed the whole patchset and
it looks fine to me".  But that information failed to make it into the
changelogs, which is bad.

I grabbed the patchset.  I might hold it over until 3.9 depending on
additional review/test feedback and upon whether Andrea can be
persuaded to take another look at it all.

I'm still a bit concerned over the possibility that some workloads will
cause a high-frequency free/alloc/memset cycle on that huge zero page. 
We'll see how it goes...

For this reason and for general ease-of-testing: can and should we add
a knob which will enable users to disable the feature at runtime?  That
way if it causes problems or if we suspect it's causing problems, we
can easily verify the theory and offer users a temporary fix.

Such a knob could be a boot-time option, but a post-boot /proc thing
would be much nicer.


WARNING: multiple messages have this Message-ID (diff)
From: Andrew Morton <akpm@linux-foundation.org>
To: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>,
	linux-mm@kvack.org, Andi Kleen <ak@linux.intel.com>,
	"H. Peter Anvin" <hpa@linux.intel.com>,
	linux-kernel@vger.kernel.org,
	"Kirill A. Shutemov" <kirill@shutemov.name>
Subject: Re: [PATCH v5 00/11] Introduce huge zero page
Date: Wed, 14 Nov 2012 13:33:42 -0800	[thread overview]
Message-ID: <20121114133342.cc7bcd6e.akpm@linux-foundation.org> (raw)
In-Reply-To: <1352300463-12627-1-git-send-email-kirill.shutemov@linux.intel.com>

On Wed,  7 Nov 2012 17:00:52 +0200
"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> wrote:

> Andrew, here's updated huge zero page patchset.

There is still a distinct lack of reviewed-by's and acked-by's on this
patchset.

On 13 Sep, Andrea did indicate that he "reviewed the whole patchset and
it looks fine to me".  But that information failed to make it into the
changelogs, which is bad.

I grabbed the patchset.  I might hold it over until 3.9 depending on
additional review/test feedback and upon whether Andrea can be
persuaded to take another look at it all.

I'm still a bit concerned over the possibility that some workloads will
cause a high-frequency free/alloc/memset cycle on that huge zero page. 
We'll see how it goes...

For this reason and for general ease-of-testing: can and should we add
a knob which will enable users to disable the feature at runtime?  That
way if it causes problems or if we suspect it's causing problems, we
can easily verify the theory and offer users a temporary fix.

Such a knob could be a boot-time option, but a post-boot /proc thing
would be much nicer.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  parent reply	other threads:[~2012-11-14 21:33 UTC|newest]

Thread overview: 84+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-07 15:00 [PATCH v5 00/11] Introduce huge zero page Kirill A. Shutemov
2012-11-07 15:00 ` Kirill A. Shutemov
2012-11-07 15:00 ` [PATCH v5 01/11] thp: huge zero page: basic preparation Kirill A. Shutemov
2012-11-07 15:00   ` Kirill A. Shutemov
2012-11-14 22:09   ` David Rientjes
2012-11-14 22:09     ` David Rientjes
2012-11-07 15:00 ` [PATCH v5 02/11] thp: zap_huge_pmd(): zap huge zero pmd Kirill A. Shutemov
2012-11-07 15:00   ` Kirill A. Shutemov
2012-11-14 22:18   ` David Rientjes
2012-11-14 22:18     ` David Rientjes
2012-11-07 15:00 ` [PATCH v5 03/11] thp: copy_huge_pmd(): copy huge zero page Kirill A. Shutemov
2012-11-07 15:00   ` Kirill A. Shutemov
2012-11-14 22:33   ` David Rientjes
2012-11-14 22:33     ` David Rientjes
2012-11-15  8:01     ` Kirill A. Shutemov
2012-11-15  8:14       ` David Rientjes
2012-11-15  8:14         ` David Rientjes
2012-11-07 15:00 ` [PATCH v5 04/11] thp: do_huge_pmd_wp_page(): handle " Kirill A. Shutemov
2012-11-07 15:00   ` Kirill A. Shutemov
2012-11-14 23:08   ` David Rientjes
2012-11-14 23:08     ` David Rientjes
2012-11-15  8:29     ` Kirill A. Shutemov
2012-11-07 15:00 ` [PATCH v5 05/11] thp: change_huge_pmd(): keep huge zero page write-protected Kirill A. Shutemov
2012-11-07 15:00   ` Kirill A. Shutemov
2012-11-14 23:12   ` David Rientjes
2012-11-14 23:12     ` David Rientjes
2012-11-15  8:46     ` Kirill A. Shutemov
2012-11-15 21:47       ` David Rientjes
2012-11-15 21:47         ` David Rientjes
2012-11-16 18:13         ` Kirill A. Shutemov
2012-11-16 20:10           ` David Rientjes
2012-11-16 20:10             ` David Rientjes
2012-11-20 16:00             ` Kirill A. Shutemov
2012-12-03  9:53               ` Kirill A. Shutemov
2012-11-07 15:00 ` [PATCH v5 06/11] thp: change split_huge_page_pmd() interface Kirill A. Shutemov
2012-11-07 15:00   ` Kirill A. Shutemov
2012-11-14 23:22   ` David Rientjes
2012-11-14 23:22     ` David Rientjes
2012-11-15  8:52     ` Kirill A. Shutemov
2012-11-07 15:00 ` [PATCH v5 07/11] thp: implement splitting pmd for huge zero page Kirill A. Shutemov
2012-11-07 15:00   ` Kirill A. Shutemov
2012-11-14 23:28   ` David Rientjes
2012-11-14 23:28     ` David Rientjes
2012-11-15  9:24     ` Kirill A. Shutemov
2012-11-07 15:01 ` [PATCH v5 08/11] thp: setup huge zero page on non-write page fault Kirill A. Shutemov
2012-11-07 15:01   ` Kirill A. Shutemov
2012-11-14 23:33   ` David Rientjes
2012-11-14 23:33     ` David Rientjes
2012-11-15  9:32     ` Kirill A. Shutemov
2012-11-15 21:52       ` David Rientjes
2012-11-15 21:52         ` David Rientjes
2012-11-16 18:20         ` Kirill A. Shutemov
2012-11-07 15:01 ` [PATCH v5 09/11] thp: lazy huge zero page allocation Kirill A. Shutemov
2012-11-07 15:01   ` Kirill A. Shutemov
2012-11-14 23:37   ` David Rientjes
2012-11-14 23:37     ` David Rientjes
2012-11-15  9:41     ` Kirill A. Shutemov
2012-12-12 21:30       ` Andrew Morton
2012-12-12 21:30         ` Andrew Morton
2012-12-12 21:48         ` H. Peter Anvin
2012-12-12 21:48           ` H. Peter Anvin
2012-12-12 22:05           ` Kirill A. Shutemov
2012-11-07 15:01 ` [PATCH v5 10/11] thp: implement refcounting for huge zero page Kirill A. Shutemov
2012-11-07 15:01   ` Kirill A. Shutemov
2012-11-14 23:40   ` David Rientjes
2012-11-14 23:40     ` David Rientjes
2012-11-15  9:50     ` Kirill A. Shutemov
2012-11-07 15:01 ` [PATCH v5 11/11] thp, vmstat: implement HZP_ALLOC and HZP_ALLOC_FAILED events Kirill A. Shutemov
2012-11-07 15:01   ` Kirill A. Shutemov
2012-11-14 23:41   ` David Rientjes
2012-11-14 23:41     ` David Rientjes
2012-11-16 21:29     ` H. Peter Anvin
2012-11-16 21:29       ` H. Peter Anvin
2012-11-14 21:33 ` Andrew Morton [this message]
2012-11-14 21:33   ` [PATCH v5 00/11] Introduce huge zero page Andrew Morton
2012-11-14 23:20   ` Alan Cox
2012-11-14 23:20     ` Alan Cox
2012-11-14 23:32     ` Andrew Morton
2012-11-14 23:32       ` Andrew Morton
2012-11-14 23:51       ` H. Peter Anvin
2012-11-14 23:51         ` H. Peter Anvin
2012-11-15  0:29   ` David Rientjes
2012-11-15  0:29     ` David Rientjes
2012-11-15  7:29   ` Kirill A. Shutemov

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=20121114133342.cc7bcd6e.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=aarcange@redhat.com \
    --cc=ak@linux.intel.com \
    --cc=hpa@linux.intel.com \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=kirill@shutemov.name \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.