From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <43699573.4070301@yahoo.com.au> Date: Thu, 03 Nov 2005 15:43:31 +1100 From: Nick Piggin MIME-Version: 1.0 Subject: Re: [Lhms-devel] [PATCH 0/7] Fragmentation Avoidance V19 References: <436888E7.1060609@yahoo.com.au> <200511021747.45599.rob@landley.net> In-Reply-To: <200511021747.45599.rob@landley.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org Return-Path: To: Rob Landley Cc: Gerrit Huizenga , Ingo Molnar , Kamezawa Hiroyuki , Dave Hansen , Mel Gorman , "Martin J. Bligh" , Andrew Morton , kravetz@us.ibm.com, linux-mm , Linux Kernel Mailing List , lhms List-ID: Rob Landley wrote: > In the UML case, I want the system to automatically be able to hand back any > sufficiently large chunks of memory it currently isn't using. > I'd just be happy with UML handing back page sized chunks of memory that it isn't currently using. How does contiguous memory (in either the host or the guest) help this? > What does this have to do with specifying hard limits of anything? What's to > specify? Workloads vary. Deal with it. > Umm, if you hadn't bothered to read the thread then I won't go through it all again. The short of it is that if you want guaranteed unfragmented memory you have to specify a limit. > >>If there are zone rebalancing problems[*], then it would be great to >>have more users of zones because then they will be more likely to get >>fixed. > > > Ok, so you want to artificially turn this into a zone balancing issue in hopes > of giving that area of the code more testing when, if zones weren't involved, > there would be no need for balancing at all? > > How does that make sense? > Have you looked at the frag patches? Do you realise that they have to balance between the different types of memory blocks? Duplicating the same or similar infrastructure (in this case, a memory zoning facility) is a bad thing in general. > >>[*] and there are, sadly enough - see the recent patches I posted to >> lkml for example. > > > I was under the impression that zone balancing is, conceptually speaking, a > difficult problem. > I am under the impression that you think proper fragmentation avoidance is easier. > >> But I'm fairly confident that once the particularly >> silly ones have been fixed, > > > Great, you're advocating migrating the fragmentation patches to an area of > code that has known problems you yourself describe as "particularly silly". > A ringing endorsement, that. > Err, the point is so we don't now have 2 layers doing very similar things, at least one of which has "particularly silly" bugs in it. > The fact that the migrated version wouldn't even address fragmentation > avoidance at all (the topic of this thread!) is apparently a side issue. > Zones can be used to guaranteee physically contiguous regions with exactly the same effectiveness as the frag patches. > >> zone balancing will no longer be a >> derogatory term as has been thrown around (maybe rightly) in this >> thread! > > > If I'm not mistaken, you introduced zones into this thread, you are the > primary (possibly only) proponent of them. So you didn't look at Yasunori Goto's patch from last year that implements exactly what I described, then? > Yes, zones are a way of categorizing memory. Yes, have you read Mel's patches? Guess what they do? > They're not a way of defragmenting it. Guess what they don't? Send instant messages to your online friends http://au.messenger.yahoo.com -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org