Re: [PATCH] x86: mtrr cleanup for converting continuous to discrete- auto detect

[Mika Fischer]

Yinghai Lu schrieb:
> On Thu, May 1, 2008 at 5:09 AM, Mika Fischer <mika.fischer@xxxxxxxxxx> wrote:
>> Yinghai Lu schrieb:
>>
>>> loop mtrr chunk_size and gran_size from 1M to 2G to find out optimal value.
>>  >
>>  > so user don't need to add mtrr_chunk_size and mtrr_gran_size,
>>  >
>>  > if optimal value is not found, print out all list to help select less optimal
>>  > value.
>>  >
>>  > add mtrr_spare_reg_nr= so user could set 2 instead of 1, if the card need more entries.
>>
>>  On my system x86-latest + this patch and using no boot options gives me
>>  this /proc/mtrr:
>>  reg00: base=0x00000000 (   0MB), size=2048MB: write-back, count=1
>>  reg01: base=0x80000000 (2048MB), size= 512MB: write-back, count=1
>>  reg02: base=0xa0000000 (2560MB), size= 256MB: write-back, count=1
>>  reg03: base=0xb0000000 (2816MB), size= 256MB: write-back, count=1
>>  reg04: base=0xbf700000 (3063MB), size=   1MB: uncachable, count=1
>>  reg05: base=0xbf800000 (3064MB), size=   8MB: uncachable, count=1
>>  reg06: base=0x100000000 (4096MB), size=1024MB: write-back, count=1
>>
>>  Which is OK. It could probably collapse reg01-reg03 into one but that's
>>  a minor issue (for me at least, there are probably cases where
>>  collapsing them might save the user from having to specify the
>>  mtrr_spare_reg_nr boot option).
> 
> yes. please try mtrr_spare_reg_nr=3 or etc.

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/