Re: [mm PATCH 0/3] Page fragment updates

2016-12-20 Thread Alexander Duyck
On Mon, Dec 5, 2016 at 12:11 PM, Andrew Morton
 wrote:
> On Mon, 5 Dec 2016 09:01:12 -0800 Alexander Duyck  
> wrote:
>
>> On Tue, Nov 29, 2016 at 10:23 AM, Alexander Duyck
>>  wrote:
>> > This patch series takes care of a few cleanups for the page fragments API.
>> >
>> > ...
>>
>> It's been about a week since I submitted this series.  Just wanted to
>> check in and see if anyone had any feedback or if this is good to be
>> accepted for 4.10-rc1 with the rest of the set?
>
> Looks good to me.  I have it all queued for post-4.9 processing.

So I guess there is a small bug in the first patch in that I was
comparing a pointer to to 0 instead of NULL.  Just wondering if I
should resubmit the first patch, the whole series, or if I need to
just submit an incremental patch.

Thanks.

- Alex


Re: [mm PATCH 0/3] Page fragment updates

2016-12-20 Thread Alexander Duyck
On Mon, Dec 5, 2016 at 12:11 PM, Andrew Morton
 wrote:
> On Mon, 5 Dec 2016 09:01:12 -0800 Alexander Duyck  
> wrote:
>
>> On Tue, Nov 29, 2016 at 10:23 AM, Alexander Duyck
>>  wrote:
>> > This patch series takes care of a few cleanups for the page fragments API.
>> >
>> > ...
>>
>> It's been about a week since I submitted this series.  Just wanted to
>> check in and see if anyone had any feedback or if this is good to be
>> accepted for 4.10-rc1 with the rest of the set?
>
> Looks good to me.  I have it all queued for post-4.9 processing.

So I guess there is a small bug in the first patch in that I was
comparing a pointer to to 0 instead of NULL.  Just wondering if I
should resubmit the first patch, the whole series, or if I need to
just submit an incremental patch.

Thanks.

- Alex


Re: [mm PATCH 0/3] Page fragment updates

2016-12-05 Thread Andrew Morton
On Mon, 5 Dec 2016 09:01:12 -0800 Alexander Duyck  
wrote:

> On Tue, Nov 29, 2016 at 10:23 AM, Alexander Duyck
>  wrote:
> > This patch series takes care of a few cleanups for the page fragments API.
> >
> > ...
> 
> It's been about a week since I submitted this series.  Just wanted to
> check in and see if anyone had any feedback or if this is good to be
> accepted for 4.10-rc1 with the rest of the set?

Looks good to me.  I have it all queued for post-4.9 processing.


Re: [mm PATCH 0/3] Page fragment updates

2016-12-05 Thread Andrew Morton
On Mon, 5 Dec 2016 09:01:12 -0800 Alexander Duyck  
wrote:

> On Tue, Nov 29, 2016 at 10:23 AM, Alexander Duyck
>  wrote:
> > This patch series takes care of a few cleanups for the page fragments API.
> >
> > ...
> 
> It's been about a week since I submitted this series.  Just wanted to
> check in and see if anyone had any feedback or if this is good to be
> accepted for 4.10-rc1 with the rest of the set?

Looks good to me.  I have it all queued for post-4.9 processing.


Re: [mm PATCH 0/3] Page fragment updates

2016-12-05 Thread Alexander Duyck
On Tue, Nov 29, 2016 at 10:23 AM, Alexander Duyck
 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.
>
> Second I did some minor clean-up on the function calls so that they are
> more inline with the existing __free_pages calls in terms of how they
> operate.
>
> 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.
>
> ---
>
> Alexander Duyck (3):
>   mm: Rename __alloc_page_frag to page_frag_alloc and __free_page_frag to 
> page_frag_free
>   mm: Rename __page_frag functions to __page_frag_cache, drop order from 
> drain
>   mm: Add documentation for page fragment APIs
>
>
>  Documentation/vm/page_frags   |   42 
> +
>  drivers/net/ethernet/intel/igb/igb_main.c |6 ++--
>  include/linux/gfp.h   |9 +++---
>  include/linux/skbuff.h|2 +
>  mm/page_alloc.c   |   33 +--
>  net/core/skbuff.c |8 +++---
>  6 files changed, 73 insertions(+), 27 deletions(-)
>  create mode 100644 Documentation/vm/page_frags
>
> --

It's been about a week since I submitted this series.  Just wanted to
check in and see if anyone had any feedback or if this is good to be
accepted for 4.10-rc1 with the rest of the set?

Thanks.

- Alex


Re: [mm PATCH 0/3] Page fragment updates

2016-12-05 Thread Alexander Duyck
On Tue, Nov 29, 2016 at 10:23 AM, Alexander Duyck
 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.
>
> Second I did some minor clean-up on the function calls so that they are
> more inline with the existing __free_pages calls in terms of how they
> operate.
>
> 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.
>
> ---
>
> Alexander Duyck (3):
>   mm: Rename __alloc_page_frag to page_frag_alloc and __free_page_frag to 
> page_frag_free
>   mm: Rename __page_frag functions to __page_frag_cache, drop order from 
> drain
>   mm: Add documentation for page fragment APIs
>
>
>  Documentation/vm/page_frags   |   42 
> +
>  drivers/net/ethernet/intel/igb/igb_main.c |6 ++--
>  include/linux/gfp.h   |9 +++---
>  include/linux/skbuff.h|2 +
>  mm/page_alloc.c   |   33 +--
>  net/core/skbuff.c |8 +++---
>  6 files changed, 73 insertions(+), 27 deletions(-)
>  create mode 100644 Documentation/vm/page_frags
>
> --

It's been about a week since I submitted this series.  Just wanted to
check in and see if anyone had any feedback or if this is good to be
accepted for 4.10-rc1 with the rest of the set?

Thanks.

- Alex


[mm PATCH 0/3] Page fragment updates

2016-11-29 Thread Alexander Duyck
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.

Second I did some minor clean-up on the function calls so that they are
more inline with the existing __free_pages calls in terms of how they
operate.

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.

---

Alexander Duyck (3):
  mm: Rename __alloc_page_frag to page_frag_alloc and __free_page_frag to 
page_frag_free
  mm: Rename __page_frag functions to __page_frag_cache, drop order from 
drain
  mm: Add documentation for page fragment APIs


 Documentation/vm/page_frags   |   42 +
 drivers/net/ethernet/intel/igb/igb_main.c |6 ++--
 include/linux/gfp.h   |9 +++---
 include/linux/skbuff.h|2 +
 mm/page_alloc.c   |   33 +--
 net/core/skbuff.c |8 +++---
 6 files changed, 73 insertions(+), 27 deletions(-)
 create mode 100644 Documentation/vm/page_frags

--


[mm PATCH 0/3] Page fragment updates

2016-11-29 Thread Alexander Duyck
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.

Second I did some minor clean-up on the function calls so that they are
more inline with the existing __free_pages calls in terms of how they
operate.

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.

---

Alexander Duyck (3):
  mm: Rename __alloc_page_frag to page_frag_alloc and __free_page_frag to 
page_frag_free
  mm: Rename __page_frag functions to __page_frag_cache, drop order from 
drain
  mm: Add documentation for page fragment APIs


 Documentation/vm/page_frags   |   42 +
 drivers/net/ethernet/intel/igb/igb_main.c |6 ++--
 include/linux/gfp.h   |9 +++---
 include/linux/skbuff.h|2 +
 mm/page_alloc.c   |   33 +--
 net/core/skbuff.c |8 +++---
 6 files changed, 73 insertions(+), 27 deletions(-)
 create mode 100644 Documentation/vm/page_frags

--