Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S936348AbXFFXUd (ORCPT ); Wed, 6 Jun 2007 19:20:33 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751472AbXFFXU0 (ORCPT ); Wed, 6 Jun 2007 19:20:26 -0400 Received: from mga03.intel.com ([143.182.124.21]:3575 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751172AbXFFXUZ (ORCPT ); Wed, 6 Jun 2007 19:20:25 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.16,390,1175497200"; d="scan'208";a="236411452" From: Jesse Barnes To: Justin Piszcz Subject: Re: [PATCH] trim memory not covered by WB MTRRs Date: Wed, 6 Jun 2007 16:20:08 -0700 User-Agent: KMail/1.9.6 Cc: Andi Kleen , linux-kernel@vger.kernel.org, "Eric W. Biederman" References: <200706061229.24486.jesse.barnes@intel.com> <200706061528.44070.jesse.barnes@intel.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200706061620.10627.jesse.barnes@intel.com> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1304 Lines: 32 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 - 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/