Date: Mon, 8 Nov 2004 06:30:07 +1100
From: Anton Blanchard <anton@samba.org>
To: William Lee Irwin III <wli@holomorphy.com>
Cc: David Gibson <david@gibson.dropbear.id.au>, linux-kernel@vger.kernel.org,
       linuxppc64-dev@ozlabs.org, Adam Litke <agl@us.ibm.com>,
       Andy Whitworth <apw@shadowen.org>
Subject: Re: [RFC] Consolidate lots of hugepage code
Message-ID: <20041107193007.GC16976@krispykreme.ozlabs.ibm.com>
References: <20041029033708.GF12247@zax> <20041029034817.GY12934@holomorphy.com> <20041107172030.GA16976@krispykreme.ozlabs.ibm.com> <20041107192024.GM2890@holomorphy.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20041107192024.GM2890@holomorphy.com>
User-Agent: Mutt/1.5.6+20040907i
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1080
Lines: 27

 
Hi,

> It's all pretty obvious. The first is checking page size vs. cache size
> and whether it's VI or does anything unusual; thus far things look
> hopeful that flush_dcache_page() analogues are unnecessary. More
> information about Super-H is needed to wrap up what will probably be no
> more than an audit. 

Good to hear.

> The second is a triplefault on x86-64 under some
> condition involving a long-running database regression test. There has
> obviously been considerably less progress there in no small part due to
> the amount of time required to reproduce the issue.

OK. We have not seen a similar issue on ppc64 even with extensive
testing (although with HPC apps). The question is how long we should
hold off on further hugetlb development waiting for this one bug report
on a single architecture to be chased.

Anton
-
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/