ollie lho <[EMAIL PROTECTED]> writes: > On Tue, 2002-07-02 at 15:35, Eric W. Biederman wrote: > > [EMAIL PROTECTED] (Eric W. Biederman) writes: > > > > > - Initial support for > 2G ram. > > > - Sizeram now returns a list of valid ranges of ram > > > - pci resource allocation now starts at 0xC0000000 > > > > Ollie my simplified mtrr.c code has one a performance regression. It > > currently does not do the overlapping large WB mtrrs with small UC > > mtrrs tric. It only used WB mtrrs, currently. > > > > Did you handle the case that the start address of a certain memory > region is not properly aligned as MTRR want ??
Yes, I use a smaller MTRR in that case. I don't think your older code handled that, at least not in the general case. > > I'm not quite certain how important that optimization is, but I > > couldn't quite see how to clearly ensure I wasn't going to overlap, > > the next range. On a second look that information is pretty clearly > > available but I don't know if we want to consider some even more > > aggressive tricks, in mttr.c to possibly do an even better job. > > > > I'm starting to think it may be possible to create a clever recursive > > algorithm that may give us an optimal mtrr usage pattern. > > > > AFIAK, my version of mtrr.c has something called rambase which is inited > to zero before the main allocation algorithm. Can we generalize this to > rambase = mem_region_start and iterate the algorithm for every memory > region ?? That is roughly what I am doing. There are two tricky bits. 1) The unaligned start problem 2) Testing to see if an extended WB MTRR will fall over into the next region. If it does we can't use your current trick of mapping the end of the region uncached. Eric
