Messages in this thread | | | Date | Wed, 02 Nov 2005 16:09:42 +1100 | From | Nick Piggin <> | Subject | Re: [Lhms-devel] [PATCH 0/7] Fragmentation Avoidance V19 |
| |
Martin J. Bligh wrote:
>>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. > > > Mmm. Though whether any one of us will personally use each feature > is perhaps not the most ideal criteria to judge things by ;-) >
Of course, but I'd say very few people will. Then again maybe I'm just a luddite who doesn't know what's good for him ;)
> >>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). > > > If it's really 1%, yes, that's a huge problem. And yes, I agree with > you that there's a problem with the rate of change. Part of that is > a lack of performance measurement and testing, and the quality sometimes > scares me (though the last month has actually been significantly better, > the tree mostly builds and boots now!). I've tried to do something on > the testing front, but I'm acutely aware it's not sufficient by any means. >
To be honest I haven't tested so this is an unfounded guess. However it is based on what I have seen of Mel's numbers, and the fact that the kernel spends nearly 1/3rd of its time in the page allocator when running a kbuild.
I may get around to getting some real numbers when my current patch queues shrink.
>>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. > > > Sounds worth discussing. We need *some* way of dealing with fragmentation > issues. To me that means both an avoidance strategy, and an ability > to actively defragment if we need it. Linux is evolved software, it > may not be perfect at first - that's the way we work, and it's served > us well up till now. To me, that's the biggest advantage we have over > the proprietary model. >
True and I'm also annoyed that we have these issues at all. I just don't see that the avoidance strategy helps that much because as I said, you don't need to keep these lovely contiguous regions just for show (or other easy-to-reclaim user pages).
The absolute priority is to move away from higher order allocs or use fallbacks IMO. And that doesn't necessarily mean order 1 or even 2 allocations because we've don't seem to have a problem with those.
Because I want Linux to be as robust as you do.
>>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. > > > It seems inevitable that we need both physically contiguous memory > sections, and virtually contiguous in kernel space (which equates to > the same thing, unless we totally break the 1-1 P-V mapping and > lose the large page mapping for kernel, which I'd hate to do.) >
I think this isn't as bad an idea as you think. If it means those guys doing memory hotplug take a few % performance hit and nobody else has to bear the costs then that sounds great.
> >>However, for the purpose of memory hot unplug, a new zone *will* >>guarantee memory can be reclaimed and unplugged. > > > It's not just about memory hotplug. There are, as we have discussed > already, many usage for physically contiguous (and virtually contiguous) > memory segments. Focusing purely on any one of them will not solve the > issue at hand ... >
True, but we don't seem to have huge problems with other things. The main ones that have come up on lkml are e1000 which is getting fixed, and maybe XFS which I think there are also moves to improve.
-- SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com
- 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/
| |