On Thu, May 1, 2008 at 2:49 PM, H. Peter Anvin <hpa@zytor.com> wrote:
quoted text
> Yinghai Lu wrote:
>
> >
> > >
> > > >
> > > >
> > >  That's not the point.  I understand you want to flatten the layout.
> The
> > > point is: why do you need manual tunables for the algorithm to do the
> right
> > > thing?
> > >
> >
> > optimal result is not losing covering for ranges that is originally
> > covered, and still keep as many of spare mtrr entries for X server
> > driver.
> > we only have 8 mtrrs, could lose some covering because of run out of mtrr
> regs.
> > So we need to search it according to chunk/gran with ram ranges that
> > is defined by old mtrr layout.
> >
>
>  Yes.  You have a search space of less than 1000 possible combinations
> (64..20 bits), so it hardly is any reason to not search the entire universe
> of possibilities, even if by exhaustive search.

only search 78
2g, 1g, ...1m, and half matrix 13 * 6..

and don't need to search than 78.

also if we don't need to get the more spare regs than
mtrr_spare_reg_nr, we could search less... about 10 etc.

quoted text
>
>  Now, if even that searching can't come up with the optimal solution (if one
> exists) in all cases, then the algorithm is broken.

because we only have 8 mtrrs, and user may specify mtrr_spare_reg_nr =
2 or 3 to get more entries for the graphics cards...
then can not the optimal setting without losing any covering.

so if the optimal is there (only need to search to 2g), it will catch it.

YH
--
unsubscribe notice
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/