Re: [External] Re: [RFC PATCH v2 00/12] get rid of GFP_ZONE_TABLE/BAD

On Fri 25-05-18 09:43:09, Huaisheng HS1 Ye wrote: > From: Michal Hocko [mailto:mho...@kernel.org] > Sent: Thursday, May 24, 2018 8:19 PM> > > > Let me try to reply your questions. > > > Exactly, GFP_ZONE_TABLE is too complicated. I think there are two > > > advantages > > > from the series of

Re: [External] Re: [RFC PATCH v2 00/12] get rid of GFP_ZONE_TABLE/BAD

On Fri 25-05-18 09:43:09, Huaisheng HS1 Ye wrote: > From: Michal Hocko [mailto:mho...@kernel.org] > Sent: Thursday, May 24, 2018 8:19 PM> > > > Let me try to reply your questions. > > > Exactly, GFP_ZONE_TABLE is too complicated. I think there are two > > > advantages > > > from the series of

Re: [RFC PATCH v2 00/12] get rid of GFP_ZONE_TABLE/BAD

On Fri 25-05-18 05:00:44, Matthew Wilcox wrote: > On Thu, May 24, 2018 at 05:29:43PM +0200, Michal Hocko wrote: > > > ie if we had more, > > > could we solve our pain by making them more generic? > > > > Well, if you have more you will consume more bits in the struct pages, > > right? > > Not

Re: [RFC PATCH v2 00/12] get rid of GFP_ZONE_TABLE/BAD

On Fri 25-05-18 05:00:44, Matthew Wilcox wrote: > On Thu, May 24, 2018 at 05:29:43PM +0200, Michal Hocko wrote: > > > ie if we had more, > > > could we solve our pain by making them more generic? > > > > Well, if you have more you will consume more bits in the struct pages, > > right? > > Not

Re: [RFC PATCH v2 00/12] get rid of GFP_ZONE_TABLE/BAD

On Thu, May 24, 2018 at 05:29:43PM +0200, Michal Hocko wrote: > > ie if we had more, > > could we solve our pain by making them more generic? > > Well, if you have more you will consume more bits in the struct pages, > right? Not necessarily ... the zone number is stored in the struct page

Re: [RFC PATCH v2 00/12] get rid of GFP_ZONE_TABLE/BAD

On Thu, May 24, 2018 at 05:29:43PM +0200, Michal Hocko wrote: > > ie if we had more, > > could we solve our pain by making them more generic? > > Well, if you have more you will consume more bits in the struct pages, > right? Not necessarily ... the zone number is stored in the struct page

RE: [External] Re: [RFC PATCH v2 00/12] get rid of GFP_ZONE_TABLE/BAD

From: Michal Hocko [mailto:mho...@kernel.org] Sent: Thursday, May 24, 2018 8:19 PM> > > Let me try to reply your questions. > > Exactly, GFP_ZONE_TABLE is too complicated. I think there are two advantages > > from the series of patches. > > > > 1. XOR operation is simple and efficient,

RE: [External] Re: [RFC PATCH v2 00/12] get rid of GFP_ZONE_TABLE/BAD

From: Michal Hocko [mailto:mho...@kernel.org] Sent: Thursday, May 24, 2018 8:19 PM> > > Let me try to reply your questions. > > Exactly, GFP_ZONE_TABLE is too complicated. I think there are two advantages > > from the series of patches. > > > > 1. XOR operation is simple and efficient,

Re: [RFC PATCH v2 00/12] get rid of GFP_ZONE_TABLE/BAD

On Thu 24-05-18 08:18:18, Matthew Wilcox wrote: > On Thu, May 24, 2018 at 02:23:23PM +0200, Michal Hocko wrote: > > > If we had eight ZONEs, we could offer: > > > > No, please no more zones. What we have is quite a maint. burden on its > > own. Ideally we should only have lowmem, highmem and

Re: [RFC PATCH v2 00/12] get rid of GFP_ZONE_TABLE/BAD

On Thu 24-05-18 08:18:18, Matthew Wilcox wrote: > On Thu, May 24, 2018 at 02:23:23PM +0200, Michal Hocko wrote: > > > If we had eight ZONEs, we could offer: > > > > No, please no more zones. What we have is quite a maint. burden on its > > own. Ideally we should only have lowmem, highmem and

Re: [RFC PATCH v2 00/12] get rid of GFP_ZONE_TABLE/BAD

On Thu, May 24, 2018 at 02:23:23PM +0200, Michal Hocko wrote: > > If we had eight ZONEs, we could offer: > > No, please no more zones. What we have is quite a maint. burden on its > own. Ideally we should only have lowmem, highmem and special/device > zones for directly kernel accessible memory,

Re: [RFC PATCH v2 00/12] get rid of GFP_ZONE_TABLE/BAD

On Thu, May 24, 2018 at 02:23:23PM +0200, Michal Hocko wrote: > > If we had eight ZONEs, we could offer: > > No, please no more zones. What we have is quite a maint. burden on its > own. Ideally we should only have lowmem, highmem and special/device > zones for directly kernel accessible memory,

Re: [RFC PATCH v2 00/12] get rid of GFP_ZONE_TABLE/BAD

On Wed 23-05-18 22:19:19, Matthew Wilcox wrote: > On Tue, May 22, 2018 at 08:37:28PM +0200, Michal Hocko wrote: > > So why is this any better than the current code. Sure I am not a great > > fan of GFP_ZONE_TABLE because of how it is incomprehensible but this > > doesn't look too much better, yet

Re: [RFC PATCH v2 00/12] get rid of GFP_ZONE_TABLE/BAD

On Wed 23-05-18 22:19:19, Matthew Wilcox wrote: > On Tue, May 22, 2018 at 08:37:28PM +0200, Michal Hocko wrote: > > So why is this any better than the current code. Sure I am not a great > > fan of GFP_ZONE_TABLE because of how it is incomprehensible but this > > doesn't look too much better, yet

Re: [External] Re: [RFC PATCH v2 00/12] get rid of GFP_ZONE_TABLE/BAD

On Wed 23-05-18 16:07:16, Huaisheng HS1 Ye wrote: > From: Michal Hocko [mailto:mho...@kernel.org] > Sent: Wednesday, May 23, 2018 2:37 AM > > > > On Mon 21-05-18 23:20:21, Huaisheng Ye wrote: > > > From: Huaisheng Ye > > > > > > Replace GFP_ZONE_TABLE and GFP_ZONE_BAD with

Re: [External] Re: [RFC PATCH v2 00/12] get rid of GFP_ZONE_TABLE/BAD

On Wed 23-05-18 16:07:16, Huaisheng HS1 Ye wrote: > From: Michal Hocko [mailto:mho...@kernel.org] > Sent: Wednesday, May 23, 2018 2:37 AM > > > > On Mon 21-05-18 23:20:21, Huaisheng Ye wrote: > > > From: Huaisheng Ye > > > > > > Replace GFP_ZONE_TABLE and GFP_ZONE_BAD with encoded zone number. >

Re: [RFC PATCH v2 00/12] get rid of GFP_ZONE_TABLE/BAD

On Tue, May 22, 2018 at 08:37:28PM +0200, Michal Hocko wrote: > So why is this any better than the current code. Sure I am not a great > fan of GFP_ZONE_TABLE because of how it is incomprehensible but this > doesn't look too much better, yet we are losing a check for incompatible > gfp flags. The

Re: [RFC PATCH v2 00/12] get rid of GFP_ZONE_TABLE/BAD

On Tue, May 22, 2018 at 08:37:28PM +0200, Michal Hocko wrote: > So why is this any better than the current code. Sure I am not a great > fan of GFP_ZONE_TABLE because of how it is incomprehensible but this > doesn't look too much better, yet we are losing a check for incompatible > gfp flags. The

RE: [External] Re: [RFC PATCH v2 00/12] get rid of GFP_ZONE_TABLE/BAD

From: Michal Hocko [mailto:mho...@kernel.org] Sent: Wednesday, May 23, 2018 2:37 AM > > On Mon 21-05-18 23:20:21, Huaisheng Ye wrote: > > From: Huaisheng Ye > > > > Replace GFP_ZONE_TABLE and GFP_ZONE_BAD with encoded zone number. > > > > Delete ___GFP_DMA, ___GFP_HIGHMEM and

RE: [External] Re: [RFC PATCH v2 00/12] get rid of GFP_ZONE_TABLE/BAD

From: Michal Hocko [mailto:mho...@kernel.org] Sent: Wednesday, May 23, 2018 2:37 AM > > On Mon 21-05-18 23:20:21, Huaisheng Ye wrote: > > From: Huaisheng Ye > > > > Replace GFP_ZONE_TABLE and GFP_ZONE_BAD with encoded zone number. > > > > Delete ___GFP_DMA, ___GFP_HIGHMEM and ___GFP_DMA32 from

Re: [RFC PATCH v2 00/12] get rid of GFP_ZONE_TABLE/BAD

On Mon 21-05-18 23:20:21, Huaisheng Ye wrote: > From: Huaisheng Ye > > Replace GFP_ZONE_TABLE and GFP_ZONE_BAD with encoded zone number. > > Delete ___GFP_DMA, ___GFP_HIGHMEM and ___GFP_DMA32 from GFP bitmasks, > the bottom three bits of GFP mask is reserved for storing

Re: [RFC PATCH v2 00/12] get rid of GFP_ZONE_TABLE/BAD

On Mon 21-05-18 23:20:21, Huaisheng Ye wrote: > From: Huaisheng Ye > > Replace GFP_ZONE_TABLE and GFP_ZONE_BAD with encoded zone number. > > Delete ___GFP_DMA, ___GFP_HIGHMEM and ___GFP_DMA32 from GFP bitmasks, > the bottom three bits of GFP mask is reserved for storing encoded > zone number. >

Re: [RFC PATCH v2 00/12] get rid of GFP_ZONE_TABLE/BAD

From: owner-linux...@kvack.org On Behalf Of Christoph Hellwig > This seems to be missing patch 1 and generally be in somewhat odd format. > Can you try to resend it with git-send-email and against current Linus' > tree? > Sure, I will rebase them to current mainline ASAP. > Also I'd suggest you

Re: [RFC PATCH v2 00/12] get rid of GFP_ZONE_TABLE/BAD

From: owner-linux...@kvack.org On Behalf Of Christoph Hellwig > This seems to be missing patch 1 and generally be in somewhat odd format. > Can you try to resend it with git-send-email and against current Linus' > tree? > Sure, I will rebase them to current mainline ASAP. > Also I'd suggest you

Re: [RFC PATCH v2 00/12] get rid of GFP_ZONE_TABLE/BAD

This seems to be missing patch 1 and generally be in somewhat odd format. Can you try to resend it with git-send-email and against current Linus' tree? Also I'd suggest you do cleanups like adding and using __GFP_ZONE_MASK at the beginning of the series before doing any real changes.

Re: [RFC PATCH v2 00/12] get rid of GFP_ZONE_TABLE/BAD

This seems to be missing patch 1 and generally be in somewhat odd format. Can you try to resend it with git-send-email and against current Linus' tree? Also I'd suggest you do cleanups like adding and using __GFP_ZONE_MASK at the beginning of the series before doing any real changes.

[RFC PATCH v2 00/12] get rid of GFP_ZONE_TABLE/BAD

From: Huaisheng Ye Replace GFP_ZONE_TABLE and GFP_ZONE_BAD with encoded zone number. Delete ___GFP_DMA, ___GFP_HIGHMEM and ___GFP_DMA32 from GFP bitmasks, the bottom three bits of GFP mask is reserved for storing encoded zone number. The encoding method is XOR. Get zone

[RFC PATCH v2 00/12] get rid of GFP_ZONE_TABLE/BAD

From: Huaisheng Ye Replace GFP_ZONE_TABLE and GFP_ZONE_BAD with encoded zone number. Delete ___GFP_DMA, ___GFP_HIGHMEM and ___GFP_DMA32 from GFP bitmasks, the bottom three bits of GFP mask is reserved for storing encoded zone number. The encoding method is XOR. Get zone number from enum