Re: [RFC PATCH 0/5] mm, hugetlb: allocation API and migration improvements

On 12/20/2017 06:53 PM, Michal Hocko wrote: > On Wed 20-12-17 05:33:36, Naoya Horiguchi wrote: >> >> On 12/15/2017 06:33 PM, Michal Hocko wrote: >>> Naoya, >>> this has passed Mike's review (thanks for that!), you have mentioned >>> that you can pass this through your testing machinery earlier.

Re: [RFC PATCH 0/5] mm, hugetlb: allocation API and migration improvements

On 12/20/2017 06:53 PM, Michal Hocko wrote: > On Wed 20-12-17 05:33:36, Naoya Horiguchi wrote: >> >> On 12/15/2017 06:33 PM, Michal Hocko wrote: >>> Naoya, >>> this has passed Mike's review (thanks for that!), you have mentioned >>> that you can pass this through your testing machinery earlier.

Re: [RFC PATCH 0/5] mm, hugetlb: allocation API and migration improvements

On Thu 21-12-17 15:35:28, Mike Kravetz wrote: [...] > You can add, > > Reviewed-by: Mike Kravetz > > I had some concerns about transferring huge page state during migration > not specific to this patch, so I did a bunch of testing. On Fri 22-12-17 08:58:48, Naoya

Re: [RFC PATCH 0/5] mm, hugetlb: allocation API and migration improvements

On Thu 21-12-17 15:35:28, Mike Kravetz wrote: [...] > You can add, > > Reviewed-by: Mike Kravetz > > I had some concerns about transferring huge page state during migration > not specific to this patch, so I did a bunch of testing. On Fri 22-12-17 08:58:48, Naoya Horiguchi wrote: [...] > Yes,

Re: [RFC PATCH 0/5] mm, hugetlb: allocation API and migration improvements

On 12/20/2017 11:28 PM, Michal Hocko wrote: > On Wed 20-12-17 14:43:03, Mike Kravetz wrote: >> On 12/20/2017 01:53 AM, Michal Hocko wrote: >>> On Wed 20-12-17 05:33:36, Naoya Horiguchi wrote: I have one comment on the code path from mbind(2). The callback passed to migrate_pages() in

Re: [RFC PATCH 0/5] mm, hugetlb: allocation API and migration improvements

On 12/20/2017 11:28 PM, Michal Hocko wrote: > On Wed 20-12-17 14:43:03, Mike Kravetz wrote: >> On 12/20/2017 01:53 AM, Michal Hocko wrote: >>> On Wed 20-12-17 05:33:36, Naoya Horiguchi wrote: I have one comment on the code path from mbind(2). The callback passed to migrate_pages() in

Re: [RFC PATCH 0/5] mm, hugetlb: allocation API and migration improvements

On Wed 20-12-17 14:43:03, Mike Kravetz wrote: > On 12/20/2017 01:53 AM, Michal Hocko wrote: > > On Wed 20-12-17 05:33:36, Naoya Horiguchi wrote: > >> I have one comment on the code path from mbind(2). > >> The callback passed to migrate_pages() in do_mbind() (i.e. new_page()) > >> calls

Re: [RFC PATCH 0/5] mm, hugetlb: allocation API and migration improvements

On Wed 20-12-17 14:43:03, Mike Kravetz wrote: > On 12/20/2017 01:53 AM, Michal Hocko wrote: > > On Wed 20-12-17 05:33:36, Naoya Horiguchi wrote: > >> I have one comment on the code path from mbind(2). > >> The callback passed to migrate_pages() in do_mbind() (i.e. new_page()) > >> calls

Re: [RFC PATCH 0/5] mm, hugetlb: allocation API and migration improvements

On 12/20/2017 01:53 AM, Michal Hocko wrote: > On Wed 20-12-17 05:33:36, Naoya Horiguchi wrote: >> I have one comment on the code path from mbind(2). >> The callback passed to migrate_pages() in do_mbind() (i.e. new_page()) >> calls alloc_huge_page_noerr() which currently doesn't call >>

Re: [RFC PATCH 0/5] mm, hugetlb: allocation API and migration improvements

On 12/20/2017 01:53 AM, Michal Hocko wrote: > On Wed 20-12-17 05:33:36, Naoya Horiguchi wrote: >> I have one comment on the code path from mbind(2). >> The callback passed to migrate_pages() in do_mbind() (i.e. new_page()) >> calls alloc_huge_page_noerr() which currently doesn't call >>

Re: [RFC PATCH 0/5] mm, hugetlb: allocation API and migration improvements

On Wed 20-12-17 05:33:36, Naoya Horiguchi wrote: > > On 12/15/2017 06:33 PM, Michal Hocko wrote: > > Naoya, > > this has passed Mike's review (thanks for that!), you have mentioned > > that you can pass this through your testing machinery earlier. While > > I've done some testing already I would

Re: [RFC PATCH 0/5] mm, hugetlb: allocation API and migration improvements

On Wed 20-12-17 05:33:36, Naoya Horiguchi wrote: > > On 12/15/2017 06:33 PM, Michal Hocko wrote: > > Naoya, > > this has passed Mike's review (thanks for that!), you have mentioned > > that you can pass this through your testing machinery earlier. While > > I've done some testing already I would

Re: [RFC PATCH 0/5] mm, hugetlb: allocation API and migration improvements

On 12/15/2017 06:33 PM, Michal Hocko wrote: > Naoya, > this has passed Mike's review (thanks for that!), you have mentioned > that you can pass this through your testing machinery earlier. While > I've done some testing already I would really appreciate if you could > do that as well. Review

Re: [RFC PATCH 0/5] mm, hugetlb: allocation API and migration improvements

On 12/15/2017 06:33 PM, Michal Hocko wrote: > Naoya, > this has passed Mike's review (thanks for that!), you have mentioned > that you can pass this through your testing machinery earlier. While > I've done some testing already I would really appreciate if you could > do that as well. Review

Re: [RFC PATCH 0/5] mm, hugetlb: allocation API and migration improvements

Naoya, this has passed Mike's review (thanks for that!), you have mentioned that you can pass this through your testing machinery earlier. While I've done some testing already I would really appreciate if you could do that as well. Review would be highly appreciated as well. Thanks! On Mon

Re: [RFC PATCH 0/5] mm, hugetlb: allocation API and migration improvements

Naoya, this has passed Mike's review (thanks for that!), you have mentioned that you can pass this through your testing machinery earlier. While I've done some testing already I would really appreciate if you could do that as well. Review would be highly appreciated as well. Thanks! On Mon

[RFC PATCH 0/5] mm, hugetlb: allocation API and migration improvements

Hi, this is a follow up for [1] for the allocation API and [2] for the hugetlb migration. It wasn't really easy to split those into two separate patch series as they share some code. My primary motivation to touch this code is to make the gigantic pages migration working. The giga pages

[RFC PATCH 0/5] mm, hugetlb: allocation API and migration improvements

Hi, this is a follow up for [1] for the allocation API and [2] for the hugetlb migration. It wasn't really easy to split those into two separate patch series as they share some code. My primary motivation to touch this code is to make the gigantic pages migration working. The giga pages