All of lore.kernel.org
 help / color / mirror / Atom feed
From: Souptick Joarder <jrdr.linux@gmail.com>
To: Matthew Wilcox <willy@infradead.org>
Cc: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>,
	Russell King - ARM Linux <linux@armlinux.org.uk>,
	robin@protonic.nl, stefanr@s5r6.in-berlin.de, hjc@rock-chips.com,
	Heiko Stuebner <heiko@sntech.de>,
	airlied@linux.ie, robin.murphy@arm.com, iamjoonsoo.kim@lge.com,
	Andrew Morton <akpm@linux-foundation.org>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	Kees Cook <keescook@chromium.org>,
	treding@nvidia.com, Michal Hocko <mhocko@suse.com>,
	Dan Williams <dan.j.williams@intel.com>,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	Mark Rutland <mark.rutland@arm.com>,
	aryabinin@virtuozzo.com, Dmitry Vyukov <dvyukov@google.com>,
	Kate Stewart <kstewart@linuxfoundation.org>,
	tchibo@google.com, riel@redhat.com,
	Minchan Kim <minchan@kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	"Huang, Ying" <ying.huang@intel.com>,
	ak@linux.intel.com, rppt@linux.vnet.ibm.com,
	linux@dominikbrodowski.net, Arnd Bergmann <arnd@arndb.de>,
	cpandya@codeaurora.org, hannes@cmpxchg.org,
	Joe Perches <joe@perches.com>,
	mcgrof@kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org,
	linux1394-devel@lists.sourceforge.net,
	dri-devel@lists.freedesktop.org,
	linux-rockchip@lists.infradead.org, Linux-MM <linux-mm@kvack.org>
Subject: Re: [PATCH v2] mm: Introduce new function vm_insert_kmem_page
Date: Tue, 23 Oct 2018 18:45:56 +0530	[thread overview]
Message-ID: <CAFqt6zYhXDG8276VfnzrBNM9JZnBsk0YeHP+yMAELB9e+Kt8uA@mail.gmail.com> (raw)
In-Reply-To: <20181023125928.GC20085@bombadil.infradead.org>

On Tue, Oct 23, 2018 at 6:29 PM Matthew Wilcox <willy@infradead.org> wrote:
>
> On Tue, Oct 23, 2018 at 06:03:42PM +0530, Souptick Joarder wrote:
> > On Tue, Oct 23, 2018 at 5:54 PM Matthew Wilcox <willy@infradead.org> wrote:
> > > On Tue, Oct 23, 2018 at 05:44:32PM +0530, Souptick Joarder wrote:
> > > > Instruction from Matthew  Wilcox who is supervising the entire vm_fault_t
> > > > migration work :-)
> > >
> > > Hang on.  That was for the initial vm_fault_t conversion in which each
> > > step was clearly an improvement.  What you're looking at now is far
> > > from that.
> >
> > Ok. But my understanding was, the approach of vm_insert_range comes
> > into discussion as part of converting vm_insert_page into vmf_insert_page
> > which is still part of original vm_fault_t conversion discussion.  No ?
>
> No.  The initial part (converting all page fault methods to vm_fault_t)
> is done.  What remains undone (looking at akpm's tree) is changing the
> typedef of vm_fault_t from int to unsigned int.  That will prevent new
> page fault handlers with the wrong type from being added.

Ok, I will post the final typedef of vm_fault_t patch.

>
> I don't necessarily want to get rid of vm_insert_page().  Maybe it will
> make sense to do that, and maybe not.  What I do want to see is thought,
> and not "Matthew told me to do it", when I didn't.

I didn't mean it in other way. Sorry about it.
I will work on it.

WARNING: multiple messages have this Message-ID (diff)
From: Souptick Joarder <jrdr.linux@gmail.com>
To: Matthew Wilcox <willy@infradead.org>
Cc: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>,
	Russell King - ARM Linux <linux@armlinux.org.uk>,
	robin@protonic.nl, stefanr@s5r6.in-berlin.de, hjc@rock-chips.com,
	Heiko Stuebner <heiko@sntech.de>,
	airlied@linux.ie, robin.murphy@arm.com, iamjoonsoo.kim@lge.com,
	Andrew Morton <akpm@linux-foundation.org>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	Kees Cook <keescook@chromium.org>,
	treding@nvidia.com, Michal Hocko <mhocko@suse.com>,
	Dan Williams <dan.j.williams@intel.com>,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	Mark Rutland <mark.rutland@arm.com>,
	aryabinin@virtuozzo.com, Dmitry Vyukov <dvyukov@google.com>,
	Kate Stewart <kstewart@linuxfoundation.org>,
	tchibo@google.com, riel@redhat.com,
	Minchan Kim <minchan@kernel.org>, Peter Zijlstra <peterz@infrad>
Subject: Re: [PATCH v2] mm: Introduce new function vm_insert_kmem_page
Date: Tue, 23 Oct 2018 18:45:56 +0530	[thread overview]
Message-ID: <CAFqt6zYhXDG8276VfnzrBNM9JZnBsk0YeHP+yMAELB9e+Kt8uA@mail.gmail.com> (raw)
In-Reply-To: <20181023125928.GC20085@bombadil.infradead.org>

On Tue, Oct 23, 2018 at 6:29 PM Matthew Wilcox <willy@infradead.org> wrote:
>
> On Tue, Oct 23, 2018 at 06:03:42PM +0530, Souptick Joarder wrote:
> > On Tue, Oct 23, 2018 at 5:54 PM Matthew Wilcox <willy@infradead.org> wrote:
> > > On Tue, Oct 23, 2018 at 05:44:32PM +0530, Souptick Joarder wrote:
> > > > Instruction from Matthew  Wilcox who is supervising the entire vm_fault_t
> > > > migration work :-)
> > >
> > > Hang on.  That was for the initial vm_fault_t conversion in which each
> > > step was clearly an improvement.  What you're looking at now is far
> > > from that.
> >
> > Ok. But my understanding was, the approach of vm_insert_range comes
> > into discussion as part of converting vm_insert_page into vmf_insert_page
> > which is still part of original vm_fault_t conversion discussion.  No ?
>
> No.  The initial part (converting all page fault methods to vm_fault_t)
> is done.  What remains undone (looking at akpm's tree) is changing the
> typedef of vm_fault_t from int to unsigned int.  That will prevent new
> page fault handlers with the wrong type from being added.

Ok, I will post the final typedef of vm_fault_t patch.

>
> I don't necessarily want to get rid of vm_insert_page().  Maybe it will
> make sense to do that, and maybe not.  What I do want to see is thought,
> and not "Matthew told me to do it", when I didn't.

I didn't mean it in other way. Sorry about it.
I will work on it.

WARNING: multiple messages have this Message-ID (diff)
From: jrdr.linux@gmail.com (Souptick Joarder)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2] mm: Introduce new function vm_insert_kmem_page
Date: Tue, 23 Oct 2018 18:45:56 +0530	[thread overview]
Message-ID: <CAFqt6zYhXDG8276VfnzrBNM9JZnBsk0YeHP+yMAELB9e+Kt8uA@mail.gmail.com> (raw)
In-Reply-To: <20181023125928.GC20085@bombadil.infradead.org>

On Tue, Oct 23, 2018 at 6:29 PM Matthew Wilcox <willy@infradead.org> wrote:
>
> On Tue, Oct 23, 2018 at 06:03:42PM +0530, Souptick Joarder wrote:
> > On Tue, Oct 23, 2018 at 5:54 PM Matthew Wilcox <willy@infradead.org> wrote:
> > > On Tue, Oct 23, 2018 at 05:44:32PM +0530, Souptick Joarder wrote:
> > > > Instruction from Matthew  Wilcox who is supervising the entire vm_fault_t
> > > > migration work :-)
> > >
> > > Hang on.  That was for the initial vm_fault_t conversion in which each
> > > step was clearly an improvement.  What you're looking at now is far
> > > from that.
> >
> > Ok. But my understanding was, the approach of vm_insert_range comes
> > into discussion as part of converting vm_insert_page into vmf_insert_page
> > which is still part of original vm_fault_t conversion discussion.  No ?
>
> No.  The initial part (converting all page fault methods to vm_fault_t)
> is done.  What remains undone (looking at akpm's tree) is changing the
> typedef of vm_fault_t from int to unsigned int.  That will prevent new
> page fault handlers with the wrong type from being added.

Ok, I will post the final typedef of vm_fault_t patch.

>
> I don't necessarily want to get rid of vm_insert_page().  Maybe it will
> make sense to do that, and maybe not.  What I do want to see is thought,
> and not "Matthew told me to do it", when I didn't.

I didn't mean it in other way. Sorry about it.
I will work on it.

  reply	other threads:[~2018-10-23 13:16 UTC|newest]

Thread overview: 79+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-03 18:58 [PATCH v2] mm: Introduce new function vm_insert_kmem_page Souptick Joarder
2018-10-03 18:58 ` Souptick Joarder
2018-10-03 19:58 ` Miguel Ojeda
2018-10-03 19:58   ` Miguel Ojeda
2018-10-03 19:58   ` Miguel Ojeda
2018-10-04 11:56   ` Souptick Joarder
2018-10-04 11:56     ` Souptick Joarder
2018-10-04 11:56     ` Souptick Joarder
2018-10-03 20:00 ` Matthew Wilcox
2018-10-03 20:00   ` Matthew Wilcox
2018-10-03 20:00   ` Matthew Wilcox
2018-10-03 22:14   ` Russell King - ARM Linux
2018-10-03 22:14     ` Russell King - ARM Linux
2018-10-03 22:14     ` Russell King - ARM Linux
2018-10-04  0:39     ` Matthew Wilcox
2018-10-04  0:39       ` Matthew Wilcox
2018-10-04  0:39       ` Matthew Wilcox
2018-10-04 12:15     ` Souptick Joarder
2018-10-04 12:15       ` Souptick Joarder
2018-10-04 12:15       ` Souptick Joarder
2018-10-04 12:34       ` Russell King - ARM Linux
2018-10-04 12:34         ` Russell King - ARM Linux
2018-10-04 12:34         ` Russell King - ARM Linux
2018-10-04 12:34         ` Russell King - ARM Linux
2018-10-04 12:34         ` Russell King - ARM Linux
2018-10-04 18:12         ` Souptick Joarder
2018-10-04 18:12           ` Souptick Joarder
2018-10-04 18:12           ` Souptick Joarder
2018-10-04 18:17           ` Matthew Wilcox
2018-10-04 18:17             ` Matthew Wilcox
2018-10-04 18:17             ` Matthew Wilcox
2018-10-04 18:53             ` Souptick Joarder
2018-10-04 18:53               ` Souptick Joarder
2018-10-04 18:53               ` Souptick Joarder
2018-10-04 19:46               ` Miguel Ojeda
2018-10-04 19:46                 ` Miguel Ojeda
2018-10-04 19:46                 ` Miguel Ojeda
2018-10-05  5:50                 ` Souptick Joarder
2018-10-05  5:50                   ` Souptick Joarder
2018-10-05  5:50                   ` Souptick Joarder
2018-10-05  8:52                   ` Miguel Ojeda
2018-10-05  8:52                     ` Miguel Ojeda
2018-10-05  8:52                     ` Miguel Ojeda
2018-10-05 10:01                     ` Souptick Joarder
2018-10-05 10:01                       ` Souptick Joarder
2018-10-05 10:01                       ` Souptick Joarder
2018-10-05 10:49                       ` Miguel Ojeda
2018-10-05 10:49                         ` Miguel Ojeda
2018-10-05 10:49                         ` Miguel Ojeda
2018-10-05 12:11                         ` Souptick Joarder
2018-10-05 12:11                           ` Souptick Joarder
2018-10-05 12:11                           ` Souptick Joarder
2018-10-05 18:09                           ` Miguel Ojeda
2018-10-05 18:09                             ` Miguel Ojeda
2018-10-05 18:09                             ` Miguel Ojeda
2018-10-06  5:14                             ` Souptick Joarder
2018-10-06  5:14                               ` Souptick Joarder
2018-10-06  5:14                               ` Souptick Joarder
2018-10-06 10:49                               ` Miguel Ojeda
2018-10-06 10:49                                 ` Miguel Ojeda
2018-10-06 10:49                                 ` Miguel Ojeda
2018-10-23 12:14                                 ` Souptick Joarder
2018-10-23 12:14                                   ` Souptick Joarder
2018-10-23 12:14                                   ` Souptick Joarder
2018-10-23 12:24                                   ` Matthew Wilcox
2018-10-23 12:24                                     ` Matthew Wilcox
2018-10-23 12:24                                     ` Matthew Wilcox
2018-10-23 12:33                                     ` Souptick Joarder
2018-10-23 12:33                                       ` Souptick Joarder
2018-10-23 12:33                                       ` Souptick Joarder
2018-10-23 12:59                                       ` Matthew Wilcox
2018-10-23 12:59                                         ` Matthew Wilcox
2018-10-23 12:59                                         ` Matthew Wilcox
2018-10-23 13:15                                         ` Souptick Joarder [this message]
2018-10-23 13:15                                           ` Souptick Joarder
2018-10-23 13:15                                           ` Souptick Joarder
2018-10-04 18:21   ` Souptick Joarder
2018-10-04 18:21     ` Souptick Joarder
2018-10-04 18:21     ` Souptick Joarder

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=CAFqt6zYhXDG8276VfnzrBNM9JZnBsk0YeHP+yMAELB9e+Kt8uA@mail.gmail.com \
    --to=jrdr.linux@gmail.com \
    --cc=airlied@linux.ie \
    --cc=ak@linux.intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=arnd@arndb.de \
    --cc=aryabinin@virtuozzo.com \
    --cc=cpandya@codeaurora.org \
    --cc=dan.j.williams@intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=dvyukov@google.com \
    --cc=hannes@cmpxchg.org \
    --cc=heiko@sntech.de \
    --cc=hjc@rock-chips.com \
    --cc=iamjoonsoo.kim@lge.com \
    --cc=joe@perches.com \
    --cc=keescook@chromium.org \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=kstewart@linuxfoundation.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=linux1394-devel@lists.sourceforge.net \
    --cc=linux@armlinux.org.uk \
    --cc=linux@dominikbrodowski.net \
    --cc=m.szyprowski@samsung.com \
    --cc=mark.rutland@arm.com \
    --cc=mcgrof@kernel.org \
    --cc=mhocko@suse.com \
    --cc=miguel.ojeda.sandonis@gmail.com \
    --cc=minchan@kernel.org \
    --cc=peterz@infradead.org \
    --cc=riel@redhat.com \
    --cc=robin.murphy@arm.com \
    --cc=robin@protonic.nl \
    --cc=rppt@linux.vnet.ibm.com \
    --cc=stefanr@s5r6.in-berlin.de \
    --cc=tchibo@google.com \
    --cc=treding@nvidia.com \
    --cc=willy@infradead.org \
    --cc=ying.huang@intel.com \
    /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.