Cc: Andrew Morton <akpm@...>, Ingo Molnar <mingo@...>, H. Peter Anvin <hpa@...>, Thomas Gleixner <tglx@...>, Gabriel C <nix.or.die@...>, linux-kernel@vger.kernel.org <linux-kernel@...>
Sure this works. But that was my point exactly. It should be possible to
figure out the better configuration automatically so that I *don't* have
to specify mtrr_spare_reg_nr=3.
Or in other words: If there are multiple equivalent configurations that
don't lose any RAM(!), the one with the most free MTRR regs should be
preferred.
AFAICT you loop over the chunk size and stop when you have found a
configuration that leaves the number of free MTRR registers requested
(default 1).
This will almost always result in a configuration where you have
*exactly* the number of requested free regs available, even if a more
efficient configuration was possible.
What I'm suggesting is, that - in the case where no RAM is lost at this
point - the loop should continue to try and free up more registers, as
long as no RAM is lost.
I.e. even if in my case chunk_size=256M gives adequate results and
leaves me with 1 free reg, since I don't lose any RAM at this point the
loop should continue as long as I do not lose any RAM. That way it would
find the ideal chunk_size (1g) automatically.
But again, this is non-critical. But I think it might help a few users
who need more than 1 free reg, because they probably will have no idea
about the kernel option...
Regards,
Mika
--
