Re: [00/17] Large Blocksize Support V3

[mel@skynet.ie (Mel Gorman)]

On (26/04/07 18:55), Nick Piggin didst pronounce:
> Mel Gorman wrote:
> >On (26/04/07 16:50), Nick Piggin didst pronounce:
> 
> >>Fragmentation is the problem. The anti-frag patches don't actually
> >>guarantee anything about fragmentation, and even if they did, then
> >
> >
> >The grouping pages by mobility do not guarantee anything but the memory
> >partition (kernelcore= boot parameter) does give hard guarantees about
> >the amount of memory that is "movable". Of course, the partition requires
> >configuration at boot-time so it's less than ideal but it does give hard
> >guarantees.
> 
> For the hugepages people, I can understand that's a solution.

I think that's the closest you have ever come to saying fragmentation
avoidance is not a terrible idea :)

> But that's
> the last thing you want to do on a system with a limited amount of memory,
> or a regular Joe's desktop/server.
> 

Regular Joe is not going to be creating a filesystem with large blocks or
overly concerned with saturating all the disks hanging off his RAID array.
At most, he'll care about faster DVD writing and considering the number and
duration of those allocations, the system will be able to handle it. So I
don't think Regular Joe will generally care.

> >Indeed but then you have to deal with internal fragmentation 
> >for pages-larger-than-TLB-page. I'm not saying it's wrong but it does
> >come with it's own set of issues.
> 
> None of them is perfect (the ways to increase the size of pagecache pages,
> that is).
> 
> I think in the long term, TLB page sizes will probably increase a little
> bit... but if a given page size is "good enough" for a CPU, they really
> should be good enough for other hardware. I mean, come on, the CPU's TLB
> has to have a good hit ratio and handle several lookups per cycle with a
> 3-cycle latency on 3GHz+ hardware... surely a an IO controller's
> scatter-gather engine or IOMMU that has to do a few lookups per disk IO
> is nowhere near so critical as a CPU's datapath: just add a few more
> entries to it, they've already got hundreds of megs of cache, so that
> isn't an issue either.
> 

I cannot speak with authority on what IO controllers are really capable
of so maybe someone else will comment on this more.

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab