Re: [RFC] Avoiding fragmentation through different allocator

2005-01-19 Thread Mel Gorman
On Mon, 17 Jan 2005, Yasunori Goto wrote: > > Is there an architecture-independant way of finding this out? > > No. At least, I have no idea. :-( > In another mail to Matthew, I suggested that the zone->free_area_usemap could be used to track hotplug blocks of pages by either using a bit-patter

RE: [RFC] Avoiding fragmentation through different allocator

2005-01-19 Thread Mel Gorman
On Mon, 17 Jan 2005, Tolentino, Matthew E wrote: > >I considered adding a new zone but I felt it would be a massive job for > >what I considered to be a simple problem. I think my approach is nice > >and isolated within the allocator itself and will be less likely to > >affect other code. > > Just

Re: [RFC] Avoiding fragmentation through different allocator

2005-01-17 Thread Yasunori Goto
> > There are 2 types of memory hotplug. > > > > a)SMP machine case > > A some part of memory will be added and removed. > > > > b)NUMA machine case. > > Whole of a node will be able to remove and add. > > However, if a block of memory like DIMM is broken and disabled, > > Its close from a)

RE: [RFC] Avoiding fragmentation through different allocator

2005-01-17 Thread Tolentino, Matthew E
>I considered adding a new zone but I felt it would be a massive job for >what I considered to be a simple problem. I think my approach is nice >and isolated within the allocator itself and will be less likely to >affect other code. Just for clarity, I prefer this approach over adding zones, henc

Re: [RFC] Avoiding fragmentation through different allocator

2005-01-16 Thread Mel Gorman
On Sat, 15 Jan 2005, Yasunori Goto wrote: > There are 2 types of memory hotplug. > > a)SMP machine case > A some part of memory will be added and removed. > > b)NUMA machine case. > Whole of a node will be able to remove and add. > However, if a block of memory like DIMM is broken and disabl

Re: [RFC] Avoiding fragmentation through different allocator

2005-01-15 Thread Yasunori Goto
Hello. I'm also very interested in your patches, because I'm working for memory hotplug too. > On possibility is that we could say that the UserRclm and KernRclm pool > are always eligible for hotplug and have hotplug banks only satisy those > allocations pushing KernNonRclm allocations to fixed

Re: [RFC] Avoiding fragmentation through different allocator

2005-01-15 Thread Mel Gorman
On Fri, 14 Jan 2005, William Lee Irwin III wrote: > On Wed, Jan 12, 2005 at 11:31:46PM -0800, William Lee Irwin III wrote: > >> I'd expect to do better with kernel/user discrimination only, having > >> address-ordering biases in opposite directions for each case. > > On Fri, Jan 14, 2005 at 07:42: