From: Andrew Morton <akpm@linux-foundation.org>
To: Alexander Duyck <alexander.duyck@gmail.com>
Cc: intel-wired-lan@lists.osuosl.org, jeffrey.t.kirsher@intel.com,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [next PATCH v4 0/3] Page fragment updates
Date: Thu, 5 Jan 2017 16:02:02 -0800 [thread overview]
Message-ID: <20170105160202.baa14f400bfd906466a915db@linux-foundation.org> (raw)
In-Reply-To: <20170104023620.13451.80691.stgit@localhost.localdomain>
On Tue, 03 Jan 2017 18:38:48 -0800 Alexander Duyck <alexander.duyck@gmail.com> wrote:
> This patch series takes care of a few cleanups for the page fragments API.
>
> First we do some renames so that things are much more consistent. First we
> move the page_frag_ portion of the name to the front of the functions
> names. Secondly we split out the cache specific functions from the other
> page fragment functions by adding the word "cache" to the name.
>
> Finally I added a bit of documentation that will hopefully help to explain
> some of this. I plan to revisit this later as we get things more ironed
> out in the near future with the changes planned for the DMA setup to
> support eXpress Data Path.
>
> ---
>
> v2: Fixed a comparison between a void* and 0 due to copy/paste from free_pages
> v3: Updated first rename patch so that it is just a rename and doesn't impact
> the actual functionality to avoid performance regression.
> v4: Fix mangling that occured due to a bad merge fix when patches 1 and 2
> were swapped and then swapped back.
>
> I'm submitting this to Intel Wired Lan and Jeff Kirsher's "next-queue" for
> acceptance as I have a series of other patches for igb that are blocked by
> by these patches since I had to rename the functionality fo draining extra
> references.
>
> This series was going to be accepted for mmotm back when it was v1, however
> since then I found a few minor issues that needed to be fixed.
>
> I am hoping to get an Acked-by from Andrew Morton for these patches and
> then have them submitted to David Miller as he has said he will accept them
> if I get the Acked-by. In the meantime if these can be applied to
> next-queue while waiting on that Acked-by then I can submit the other
> patches for igb and ixgbe for testing.
The patches look fine. How about I just scoot them straight into
mainline next week? I do that occasionally, just to simplify ongoing
development and these patches are safe enough.
--
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>
next prev parent reply other threads:[~2017-01-06 0:00 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-04 2:38 [next PATCH v4 0/3] Page fragment updates Alexander Duyck
2017-01-04 2:39 ` [next PATCH v4 1/3] mm: Rename __alloc_page_frag to page_frag_alloc and __free_page_frag to page_frag_free Alexander Duyck
2017-01-04 2:41 ` [next PATCH v4 2/3] mm: Rename __page_frag functions to __page_frag_cache, drop order from drain Alexander Duyck
2017-01-04 2:42 ` [next PATCH v4 3/3] mm: Add documentation for page fragment APIs Alexander Duyck
2017-01-06 0:02 ` Andrew Morton [this message]
2017-01-06 0:07 ` [next PATCH v4 0/3] Page fragment updates Alexander Duyck
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=20170105160202.baa14f400bfd906466a915db@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=alexander.duyck@gmail.com \
--cc=intel-wired-lan@lists.osuosl.org \
--cc=jeffrey.t.kirsher@intel.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).