On Jan 24, 2008 12:20 AM, Yasunori Goto <[EMAIL PROTECTED]> wrote:
> This is a nitpick, but all of archtectures code except generic use
> MMF_NNED_FLUSH at clear_bit()...
I'd say that's a bit more than a nit. Thanks for noticing that.
Please hang on, I think I've figured out how to reduce the
On Jan 24, 2008 12:20 AM, Yasunori Goto [EMAIL PROTECTED] wrote:
This is a nitpick, but all of archtectures code except generic use
MMF_NNED_FLUSH at clear_bit()...
I'd say that's a bit more than a nit. Thanks for noticing that.
Please hang on, I think I've figured out how to reduce the 3.5%
---
diff -uprwNbB -X 2.6.23/Documentation/dontdiff
2.6.23/arch/i386/mm/hugetlbpage.c 2.6.23a/arch/i386/mm/hugetlbpage.c
--- 2.6.23/arch/i386/mm/hugetlbpage.c 2007-10-09 13:31:38.0 -0700
+++ 2.6.23a/arch/i386/mm/hugetlbpage.c 2007-10-29 09:48:48.0 -0700
@@ -87,6 +87,7 @@ static
From: [EMAIL PROTECTED]
These patches make page tables relocatable for numa, memory
defragmentation, and memory hotplug. The need to rewalk the page
tables before making any changes causes a 3.5% performance degredation
in the lmbench page miss micro benchmark. Please check the linux-mm
list
From: [EMAIL PROTECTED]
These patches make page tables relocatable for numa, memory
defragmentation, and memory hotplug. The need to rewalk the page
tables before making any changes causes a 3.5% performance degredation
in the lmbench page miss micro benchmark. Please check the linux-mm
list
---
diff -uprwNbB -X 2.6.23/Documentation/dontdiff
2.6.23/arch/i386/mm/hugetlbpage.c 2.6.23a/arch/i386/mm/hugetlbpage.c
--- 2.6.23/arch/i386/mm/hugetlbpage.c 2007-10-09 13:31:38.0 -0700
+++ 2.6.23a/arch/i386/mm/hugetlbpage.c 2007-10-29 09:48:48.0 -0700
@@ -87,6 +87,7 @@ static
On 8/26/05, Rik van Riel <[EMAIL PROTECTED]> wrote:
>
> Filling in all the page table entries at the first fault to
> a VMA doesn't make much sense, IMHO.
>
>
> I suspect we would be better off without that extra complexity,
> unless there is a demonstrated benefit to it.
You are probably
On 8/26/05, Hugh Dickins <[EMAIL PROTECTED]> wrote:
> On Fri, 26 Aug 2005, Ross Biro wrote:
> > On 8/26/05, Hugh Dickins <[EMAIL PROTECTED]> wrote:
> > >
> > > The refaulting will hurt the performance of something: let's
> > > just hope that
On 8/26/05, Hugh Dickins [EMAIL PROTECTED] wrote:
On Fri, 26 Aug 2005, Ross Biro wrote:
On 8/26/05, Hugh Dickins [EMAIL PROTECTED] wrote:
The refaulting will hurt the performance of something: let's
just hope that something doesn't turn out to be a show-stopper.
Why not just fault
On 8/26/05, Rik van Riel [EMAIL PROTECTED] wrote:
Filling in all the page table entries at the first fault to
a VMA doesn't make much sense, IMHO.
I suspect we would be better off without that extra complexity,
unless there is a demonstrated benefit to it.
You are probably right, but do
On 4/13/05, Dave Jones <[EMAIL PROTECTED]> wrote:
> If we have a situation where we screw a subset of users with the
> config option =y and a different subset with =n, how is this improving
> the situation any over what we have today ?
This is exactly the case and this is better than what we
On 4/13/05, Dave Jones [EMAIL PROTECTED] wrote:
If we have a situation where we screw a subset of users with the
config option =y and a different subset with =n, how is this improving
the situation any over what we have today ?
This is exactly the case and this is better than what we have
On 13 Apr 2005 20:37:25 +0200, Andi Kleen <[EMAIL PROTECTED]> wrote:
> \>
> > You're argument that no one can make sense of such options is totally off
> > base. Once you are having a problem, it's pretty easy to see if it's related
>
> I dont think it is in any way help to put suche highly
On 13 Apr 2005 20:37:25 +0200, Andi Kleen [EMAIL PROTECTED] wrote:
\
You're argument that no one can make sense of such options is totally off
base. Once you are having a problem, it's pretty easy to see if it's related
I dont think it is in any way help to put suche highly obscure
things
Randy.Dunlap wrote:
Is this related (or could it be -- or should it be) at all to the
current discussion on the linux-pci mailing list
[EMAIL PROTECTED]) about "PCI Error Recovery
API Proposal" ?
I'm not familiar with the proposal, but this is not related to error
recovery since master aborts
Randy.Dunlap wrote:
Is this related (or could it be -- or should it be) at all to the
current discussion on the linux-pci mailing list
[EMAIL PROTECTED]) about PCI Error Recovery
API Proposal ?
I'm not familiar with the proposal, but this is not related to error
recovery since master aborts are
Currently Linux 2.6 assumes the BIOS (or firmware) sets the master abort
mode flag on PCI bridge chips in a coherent fashion. This is not always
the case and the consequences of getting this flag incorrect can cause
hardware to fail or silent data corruption. This patch lets the user
Currently Linux 2.6 assumes the BIOS (or firmware) sets the master abort
mode flag on PCI bridge chips in a coherent fashion. This is not always
the case and the consequences of getting this flag incorrect can cause
hardware to fail or silent data corruption. This patch lets the user
On Tue, 08 Mar 2005 09:32:48 -0700, Peter W. Morreale
<[EMAIL PROTECTED]> wrote:
>
> This seems wrong since we've mixed locking primitives.
>
> Is it?
It's not really wrong, it just wastes time turning interrupts off over
and over again.
>
> foo()
> {
> unsigned long lflags;
At this
On Tue, 08 Mar 2005 09:32:48 -0700, Peter W. Morreale
[EMAIL PROTECTED] wrote:
This seems wrong since we've mixed locking primitives.
Is it?
It's not really wrong, it just wastes time turning interrupts off over
and over again.
foo()
{
unsigned long lflags;
At this point,
20 matches
Mail list logo
