Re: [PATCH] trim memory not covered by WB MTRRs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On Wed, 6 Jun 2007, Jesse Barnes wrote:

On Wednesday, June 6, 2007 3:57 pm Justin Piszcz wrote:
On Wed, 6 Jun 2007, Jesse Barnes wrote:
On Wednesday, June 6, 2007 3:26 pm Justin Piszcz wrote:
Nope, I booted with only netconsole= options.  I have a lot of HW
in the box and I guess the buffer is too small.  Not sure where to
change it in the kernel.  Looking..

It's called "kernel log buffer size" and it's in "General setup".

Jesse

Did the dmesg output get you what you needed?  Why the few KB
difference?

:)

Yeah, looked at your e820 and your MTRR settings and I think my patch is
doing the right thing (i.e. trimming just the right amount of memory,
leaving you with as much as possible).

The mem= approach though looks slightly off, but I haven't looked at
x86_64's mem= handling to see why.  From a high level though, adjusting
end_pfn is the right thing to do, since theoretically mem= could choose
to make holes in your low memory and keep your high memory in the
allocation pools (though it's not generally implemented this way).

Jesse


Ahh, ok! Sounds great, I will keep running the kernel with your patch without mem= and let you know if I see any issues.

Chances of getting this into 2.6.22-rc5?

Justin.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux