Re: [RFC V2 03/12] mm: Change generic FALLBACK zonelist creation process

2017-01-31 Thread Anshuman Khandual
On 01/31/2017 11:34 PM, Dave Hansen wrote: > On 01/30/2017 11:25 PM, John Hubbard wrote: >> I also don't like having these policies hard-coded, and your 100x >> example above helps clarify what can go wrong about it. It would be >> nicer if, instead, we could better express the "distance" between n

Re: [RFC V2 03/12] mm: Change generic FALLBACK zonelist creation process

2017-01-31 Thread Anshuman Khandual
On 01/31/2017 12:55 PM, John Hubbard wrote: > On 01/30/2017 05:57 PM, Dave Hansen wrote: >> On 01/30/2017 05:36 PM, Anshuman Khandual wrote: Let's say we had a CDM node with 100x more RAM than the rest of the system and it was just as fast as the rest of the RAM. Would we still want

Re: [RFC V2 03/12] mm: Change generic FALLBACK zonelist creation process

2017-01-31 Thread Anshuman Khandual
On 01/31/2017 07:27 AM, Dave Hansen wrote: > On 01/30/2017 05:36 PM, Anshuman Khandual wrote: >>> Let's say we had a CDM node with 100x more RAM than the rest of the >>> system and it was just as fast as the rest of the RAM. Would we still >>> want it isolated like this? Or would we want a differ

Re: [RFC V2 03/12] mm: Change generic FALLBACK zonelist creation process

2017-01-31 Thread David Nellans
On 01/31/2017 12:04 PM, Dave Hansen wrote: > On 01/30/2017 11:25 PM, John Hubbard wrote: >> I also don't like having these policies hard-coded, and your 100x >> example above helps clarify what can go wrong about it. It would be >> nicer if, instead, we could better express the "distance" between

Re: [RFC V2 03/12] mm: Change generic FALLBACK zonelist creation process

2017-01-31 Thread Dave Hansen
On 01/30/2017 11:25 PM, John Hubbard wrote: > I also don't like having these policies hard-coded, and your 100x > example above helps clarify what can go wrong about it. It would be > nicer if, instead, we could better express the "distance" between nodes > (bandwidth, latency, relative to sysmem,

Re: [RFC V2 03/12] mm: Change generic FALLBACK zonelist creation process

2017-01-30 Thread John Hubbard
On 01/30/2017 05:57 PM, Dave Hansen wrote: On 01/30/2017 05:36 PM, Anshuman Khandual wrote: Let's say we had a CDM node with 100x more RAM than the rest of the system and it was just as fast as the rest of the RAM. Would we still want it isolated like this? Or would we want a different policy?

Re: [RFC V2 03/12] mm: Change generic FALLBACK zonelist creation process

2017-01-30 Thread Dave Hansen
On 01/30/2017 05:36 PM, Anshuman Khandual wrote: >> Let's say we had a CDM node with 100x more RAM than the rest of the >> system and it was just as fast as the rest of the RAM. Would we still >> want it isolated like this? Or would we want a different policy? > > But then the other argument bei

Re: [RFC V2 03/12] mm: Change generic FALLBACK zonelist creation process

2017-01-30 Thread Anshuman Khandual
On 01/30/2017 11:04 PM, Dave Hansen wrote: > On 01/29/2017 07:35 PM, Anshuman Khandual wrote: >> * CDM node's zones are not part of any other node's FALLBACK zonelist >> * CDM node's FALLBACK list contains it's own memory zones followed by >> all system RAM zones in regular order as before >> * C

Re: [RFC V2 03/12] mm: Change generic FALLBACK zonelist creation process

2017-01-30 Thread Dave Hansen
On 01/29/2017 07:35 PM, Anshuman Khandual wrote: > * CDM node's zones are not part of any other node's FALLBACK zonelist > * CDM node's FALLBACK list contains it's own memory zones followed by > all system RAM zones in regular order as before > * CDM node's zones are part of it's own NOFALLBACK z

[RFC V2 03/12] mm: Change generic FALLBACK zonelist creation process

2017-01-29 Thread Anshuman Khandual
Kernel allocation to CDM node has already been prevented by putting it's entire memory in ZONE_MOVABLE. But the CDM nodes must also be isolated from implicit allocations happening on the system. Any isolation seeking CDM node requires isolation from implicit memory allocations from user space but