Messages in this thread |  | | | Date | Wed, 2 Nov 2005 11:48:07 +0000 (GMT) | | From | Mel Gorman <> | | Subject | Re: [Lhms-devel] [PATCH 0/7] Fragmentation Avoidance V19 |
| |
On Wed, 2 Nov 2005, Nick Piggin wrote:
> Martin J. Bligh wrote: > > > > But let's move this to another thread if it is going to continue. I > > > would be happy to discuss scheduler problems. > > > > > > My point was that most things we do add complexity to the codebase, > > including the things you do yourself ... I'm not saying the we're worse > > off for the changes you've made, by any means - I think they've been > > mostly beneficial. > > Heh - I like the "mostly" ;) > > > I'm just pointing out that we ALL do it, so let us > > not be too quick to judge when others propose adding something that does ;-) > > > > What I'm getting worried about is the marked increase in the > rate of features and complexity going in. > > I am almost certainly never going to use memory hotplug or > demand paging of hugepages. I am pretty likely going to have > to wade through this code at some point in the future if it > is merged. >
Plenty of features in the kernel I don't use either :) .
> It is also going to slow down my kernel by maybe 1% when > doing kbuilds, but hey let's not worry about that until we've > merged 10 more such slowdowns (ok that wasn't aimed at you or > Mel, but my perception of the status quo). >
Ok, my patches show performance gains and losses on different parts of Aim9. page_test is slightly down but fork_test was considerably up. Both would have an effect on kbuild so more figures are needed on mode machines. That will only be found from testing from a variety of machines.
> > > > > You can't what? What doesn't work? If you have no hard limits set, > > > then the frag patches can't guarantee anything either. > > > > > > You can't have it both ways. Either you have limits for things or > > > you don't need any guarantees. Zones handle the former case nicely, > > > and we currently do the latter case just fine (along with the frag > > > patches). > > > > > > I'll go look through Mel's current patchset again. I was under the > > impression it didn't suffer from this problem, at least not as much > > as zones did. > > > > Over time, I don't think it can offer any stronger a guarantee > than what we currently have. I'm not even sure that it would be > any better at all for problematic workloads as time -> infinity. >
Not as they currently stand no. As I've said elsewhere, to really guarantee things, kswapd would need to know how to clear out UesrRclm pages from the other reserve types.
> > Nothing is guaranteed. You can shag the whole machine and/or VM in > > any number of ways ... if we can significantly improve the probability of > > existing higher order allocs working, and new functionality has > > an excellent probability of success, that's as good as you're going to get. > > Have a free "perfect is the enemy of good" Linus quote, on me ;-) > > > > I think it falls down if these higher order allocations actually > get *used* for anything. You'll simply be going through the process > of replacing your contiguous, easy-to-reclaim memory with pinned > kernel memory. >
And a misconfigured zone-based approach just falls apart. Going to finish that summary mail to avoid repetition.
> However, for the purpose of memory hot unplug, a new zone *will* > guarantee memory can be reclaimed and unplugged. >
>
-- Mel Gorman Part-time Phd Student Java Applications Developer University of Limerick IBM Dublin Software Lab - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |