On Wed, 30 Mar 2005 13:22:53 +0100 (BST)
Hugh Dickins <[EMAIL PROTECTED]> wrote:
> Sounds like we should leave flush_tlb_pgtables as it is
> (apart from the issue in its frv implementation that you noticed).
Ok. I may still adjust the pmd_clear() args.
-
To unsubscribe from this list: send the
On Wed, 30 Mar 2005 13:22:53 +0100 (BST)
Hugh Dickins [EMAIL PROTECTED] wrote:
Sounds like we should leave flush_tlb_pgtables as it is
(apart from the issue in its frv implementation that you noticed).
Ok. I may still adjust the pmd_clear() args.
-
To unsubscribe from this list: send the line
On Mon, 28 Mar 2005 21:34:08 -0500
Ananth N Mavinakayanahalli <[EMAIL PROTECTED]> wrote:
> You are right. The check for pre_handler is needed and here is a patch
> against 2.6.12-rc1-mm3 that does this.
The sparc64 part looks just fine.
-
To unsubscribe from this list: send the line "unsubscribe
On Mon, 28 Mar 2005 08:51:36 +0100
Russell King <[EMAIL PROTECTED]> wrote:
> Why would I want to do this, given that decrementing mm->nr_ptes in
> free_pgd_slow() would make it negative ? Am I missing something
> obvious?
You were saying there was no way to figure out which mm is
assosociate a
On Mon, 28 Mar 2005 08:51:36 +0100
Russell King [EMAIL PROTECTED] wrote:
Why would I want to do this, given that decrementing mm-nr_ptes in
free_pgd_slow() would make it negative ? Am I missing something
obvious?
You were saying there was no way to figure out which mm is
assosociate a
On Mon, 28 Mar 2005 21:34:08 -0500
Ananth N Mavinakayanahalli [EMAIL PROTECTED] wrote:
You are right. The check for pre_handler is needed and here is a patch
against 2.6.12-rc1-mm3 that does this.
The sparc64 part looks just fine.
-
To unsubscribe from this list: send the line unsubscribe
On 27 Mar 2005 19:12:20 +0200
Andi Kleen <[EMAIL PROTECTED]> wrote:
> With non temporal stores
> you guarantee at least one hard cache miss directly after
> the return to user space.
This is true if the cacheline were not present already at
the time of the non-temporal store.
I know what you're
On Sun, 27 Mar 2005 08:57:25 +0100
Russell King <[EMAIL PROTECTED]> wrote:
> Unfortunately not - free_pgd_slow doesn't have any knowledge about the
> mm_struct that the pgd was associated with.
You could store the mm pointer in the page struct of the
pgd, we used to that before set_pte_at()
On Sun, 27 Mar 2005 08:57:25 +0100
Russell King [EMAIL PROTECTED] wrote:
Unfortunately not - free_pgd_slow doesn't have any knowledge about the
mm_struct that the pgd was associated with.
You could store the mm pointer in the page struct of the
pgd, we used to that before set_pte_at() existed
On 27 Mar 2005 19:12:20 +0200
Andi Kleen [EMAIL PROTECTED] wrote:
With non temporal stores
you guarantee at least one hard cache miss directly after
the return to user space.
This is true if the cacheline were not present already at
the time of the non-temporal store.
I know what you're
This should go through Jeff Garzik, at least let him review and look
over it.
-
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
This should go through Jeff Garzik, at least let him review and look
over it.
-
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
On Fri, 25 Mar 2005 09:23:12 -0800
"David S. Miller" <[EMAIL PROTECTED]> wrote:
> On Fri, 25 Mar 2005 16:32:07 +1100
> Nick Piggin <[EMAIL PROTECTED]> wrote:
>
> > So, to make the question more concrete: if a pgd_t is freed due
> > to freeing
On Fri, 25 Mar 2005 15:34:41 +0100
Ingo Molnar <[EMAIL PROTECTED]> wrote:
> the patch below fixes a bug that i encountered while running a
> PREEMPT_RT kernel, but i believe it should be fixed in the generic
> kernel too. xfrm_policy_kill() queues a destroyed policy structure to
> the GC list,
On Fri, 25 Mar 2005 16:35:12 +1100
Nick Piggin <[EMAIL PROTECTED]> wrote:
> Oh - one other question too. Doing the unmap and page table freeing in
> the same pass will put freed pagecache pages in the same mmu_gather as
> the freed page table pages. This looks like it may be a problem for
>
On Fri, 25 Mar 2005 16:32:07 +1100
Nick Piggin <[EMAIL PROTECTED]> wrote:
> So, to make the question more concrete: if a pgd_t is freed due
> to freeing the single pmd_t contained within it (which was the
> only part of the pgd's address space that contained a valid mapping)
> Then do you need
On Fri, 25 Mar 2005 16:32:07 +1100
Nick Piggin [EMAIL PROTECTED] wrote:
So, to make the question more concrete: if a pgd_t is freed due
to freeing the single pmd_t contained within it (which was the
only part of the pgd's address space that contained a valid mapping)
Then do you need the full
On Fri, 25 Mar 2005 16:35:12 +1100
Nick Piggin [EMAIL PROTECTED] wrote:
Oh - one other question too. Doing the unmap and page table freeing in
the same pass will put freed pagecache pages in the same mmu_gather as
the freed page table pages. This looks like it may be a problem for
sparc64?
On Fri, 25 Mar 2005 15:34:41 +0100
Ingo Molnar [EMAIL PROTECTED] wrote:
the patch below fixes a bug that i encountered while running a
PREEMPT_RT kernel, but i believe it should be fixed in the generic
kernel too. xfrm_policy_kill() queues a destroyed policy structure to
the GC list, and
On Fri, 25 Mar 2005 09:23:12 -0800
David S. Miller [EMAIL PROTECTED] wrote:
On Fri, 25 Mar 2005 16:32:07 +1100
Nick Piggin [EMAIL PROTECTED] wrote:
So, to make the question more concrete: if a pgd_t is freed due
to freeing the single pmd_t contained within it (which was the
only part
On Thu, 24 Mar 2005 14:49:55 -0800 (PST)
Christoph Lameter <[EMAIL PROTECTED]> wrote:
> Could you help me fix up this patch replacing the old clear_pages patch?
Ok, first you need to mark the order and gfp arguments as unsigned
for mm/page_alloc.c:prep_zero_page() so that it matches the
On Thu, 24 Mar 2005 14:49:55 -0800 (PST)
Christoph Lameter <[EMAIL PROTECTED]> wrote:
> On Thu, 24 Mar 2005, David S. Miller wrote:
>
> > > prep_zero_page would use a temporal clear for an order 0 page but a
> > > nontemporal clear for higher order pages.
> &g
On Thu, 24 Mar 2005 10:41:06 -0800 (PST)
Christoph Lameter <[EMAIL PROTECTED]> wrote:
> So it would be useful to have
>
> clear_page-> Temporal. Only zaps one page
>
> and
>
> clear_pages -> Zaps arbitrary order of page non-temporal
>
>
> Rework the clear_pages patch to do just
On Thu, 24 Mar 2005 10:41:06 -0800 (PST)
Christoph Lameter [EMAIL PROTECTED] wrote:
So it would be useful to have
clear_page- Temporal. Only zaps one page
and
clear_pages - Zaps arbitrary order of page non-temporal
Rework the clear_pages patch to do just that? Maybe
On Thu, 24 Mar 2005 14:49:55 -0800 (PST)
Christoph Lameter [EMAIL PROTECTED] wrote:
On Thu, 24 Mar 2005, David S. Miller wrote:
prep_zero_page would use a temporal clear for an order 0 page but a
nontemporal clear for higher order pages.
That sounds about right to me.
Hmmm, I'm
On Thu, 24 Mar 2005 14:49:55 -0800 (PST)
Christoph Lameter [EMAIL PROTECTED] wrote:
Could you help me fix up this patch replacing the old clear_pages patch?
Ok, first you need to mark the order and gfp arguments as unsigned
for mm/page_alloc.c:prep_zero_page() so that it matches the prototype
On Thu, 24 Mar 2005 11:26:16 +1100
Nick Piggin <[EMAIL PROTECTED]> wrote:
> OK, attached is my first cut at slimming down the boundary tests.
Works perfectly fine on sparc64.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
On Wed, 23 Mar 2005 15:28:23 -0500
Jeff Garzik <[EMAIL PROTECTED]> wrote:
> Note that I apply drivers/net/* stuff too, including this one... :)
I realized this was a possibility, BK will figure it out once
it gets merged so no worries.
Generally, besides bonding, I pretty much take the changes
On Tue, 22 Mar 2005 22:53:54 +0100
Adrian Bunk <[EMAIL PROTECTED]> wrote:
> This patch removes some obviously dead code found by the Coverity
> checker.
>
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
Applied, thanks Adrian.
-
To unsubscribe from this list: send the line "unsubscribe
On Tue, 22 Mar 2005 22:25:04 +1100
Herbert Xu <[EMAIL PROTECTED]> wrote:
> Hi:
>
> This is needed so that we can keep the in_place assignment outside the
> inner loop. Without this in pathalogical situations we can start out
> having walk_out being different from walk_in, but when walk_out
On Wed, 23 Mar 2005 17:10:15 + (GMT)
Hugh Dickins <[EMAIL PROTECTED]> wrote:
> Here's the recut of those patches, including David Miller's vital fixes.
> I'm addressing these to Nick rather than Andrew, because they're perhaps
> not fit for -mm until more testing done and the x86_64 32-bit
On Wed, 23 Mar 2005 11:16:27 -0800
"Luck, Tony" <[EMAIL PROTECTED]> wrote:
> Can we legislate that "end==0" isn't possible.
It is possible with some out-of-tree patches.
I could certainly support it on sparc64, the only
glitch is that this is where the virtually mapped
linear page tables sit
On Wed, 23 Mar 2005 11:32:00 -0500
Jeff Garzik <[EMAIL PROTECTED]> wrote:
> I wonder if its 4-level page tables. I think DaveM, in another thread,
> is chasing flush- issues right now, on sparc64.
It has to do with Hugh Dickin's patches which haven't been
integrated yet.
It may be the case
On Wed, 23 Mar 2005 11:32:00 -0500
Jeff Garzik [EMAIL PROTECTED] wrote:
I wonder if its 4-level page tables. I think DaveM, in another thread,
is chasing flush-something issues right now, on sparc64.
It has to do with Hugh Dickin's patches which haven't been
integrated yet.
It may be the
On Wed, 23 Mar 2005 11:16:27 -0800
Luck, Tony [EMAIL PROTECTED] wrote:
Can we legislate that end==0 isn't possible.
It is possible with some out-of-tree patches.
I could certainly support it on sparc64, the only
glitch is that this is where the virtually mapped
linear page tables sit right now
On Wed, 23 Mar 2005 17:10:15 + (GMT)
Hugh Dickins [EMAIL PROTECTED] wrote:
Here's the recut of those patches, including David Miller's vital fixes.
I'm addressing these to Nick rather than Andrew, because they're perhaps
not fit for -mm until more testing done and the x86_64 32-bit vdso
On Tue, 22 Mar 2005 22:25:04 +1100
Herbert Xu [EMAIL PROTECTED] wrote:
Hi:
This is needed so that we can keep the in_place assignment outside the
inner loop. Without this in pathalogical situations we can start out
having walk_out being different from walk_in, but when walk_out crosses
a
On Tue, 22 Mar 2005 22:53:54 +0100
Adrian Bunk [EMAIL PROTECTED] wrote:
This patch removes some obviously dead code found by the Coverity
checker.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
Applied, thanks Adrian.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
On Wed, 23 Mar 2005 15:28:23 -0500
Jeff Garzik [EMAIL PROTECTED] wrote:
Note that I apply drivers/net/* stuff too, including this one... :)
I realized this was a possibility, BK will figure it out once
it gets merged so no worries.
Generally, besides bonding, I pretty much take the changes in
On Thu, 24 Mar 2005 11:26:16 +1100
Nick Piggin [EMAIL PROTECTED] wrote:
OK, attached is my first cut at slimming down the boundary tests.
Works perfectly fine on sparc64.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More
On Fri, 18 Mar 2005 15:59:02 -0800
Jean Tourrilhes <[EMAIL PROTECTED]> wrote:
> A pretty big and tedious patch that mostly rename IrDA debug
> macros, plus a few other tiny fixes. Has been on my web pages for a
> long while, tested and rediff'd on 2.6.12-rc1. I would be grateful if
> you
On Thu, 17 Mar 2005 20:34:05 +0100 (CET)
Jesper Juhl <[EMAIL PROTECTED]> wrote:
> kfree() handles NULL pointers just fine, checking first is pointless.
>
> Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
Applied, thanks Jesper.
-
To unsubscribe from this list: send the line "unsubscribe
On Wed, 23 Mar 2005 13:10:42 +1100
Nick Piggin <[EMAIL PROTECTED]> wrote:
> The ugly thing you get with an inclusive ceiling is that your masking
> becomes more difficult I think.
Good point.
> I might try to attack this from another angle and see if I can come up
> with something.
Great, let
On Wed, 23 Mar 2005 00:51:02 + (GMT)
Hugh Dickins <[EMAIL PROTECTED]> wrote:
> This actual example helped to focus my mind a lot, thank you.
No problem, I needed to work through specific examples
to see things clearly too.
> > and things seem to behave. I'll try to analyze things
> >
On Tue, 22 Mar 2005 17:10:13 -0800
Andrew Morton <[EMAIL PROTECTED]> wrote:
> Hugh Dickins <[EMAIL PROTECTED]> wrote:
> >
> > On Tue, 22 Mar 2005, Luck, Tony wrote:
> > >
> > > But I'm still confused by all the math on addr/end at each
> > > level.
> >
> > You think the rest of us are not
On Wed, 23 Mar 2005 11:19:38 +1100
Nick Piggin <[EMAIL PROTECTED]> wrote:
> > dramatically, shell performance is way down on sparc64.
> > I'll post before and after numbers in a bit. Note, this is
> > just with Hugh's base patch plus bug fixes.
> >
>
> That's interesting. The only "extra"
Ok, this patch, on top of Hugh's original freepgt patch, gets
me a working system. It includes Hugh's bug fix, plus the
ceiling masking roll-over fix of mine.
It should get ppc working too, I bet.
--- mm/memory.c.hugh2005-03-22 16:01:07.0 -0800
+++ mm/memory.c 2005-03-22
Ok, here are (finally, I've been debugging this so much purely
to see these things) some lmbench numbers with Hugh's base
patch on sparc64.
Ignore my previous comments about shell performance getting
worse, it's some difference that makes things run more slowly
in single user mode compared to a
On Tue, 22 Mar 2005 15:53:08 -0800
"Luck, Tony" <[EMAIL PROTECTED]> wrote:
> But I'm still confused by all the math on addr/end at each
> level. Rounding up/down at each level should presumably be
> based on the size of objects at the next level. So the pgd
> code should round using PUD_MASK,
On Wed, 23 Mar 2005 10:32:10 +1100
Nick Piggin <[EMAIL PROTECTED]> wrote:
> I think David's on the right track - I think there's something a
> bit wrong at the top. In my reply to Andrew in this thread I
> posted a patch which may at least get things working...
We have to do the "if (ceiling)"
On Tue, 22 Mar 2005 14:40:55 -0800
"Luck, Tony" <[EMAIL PROTECTED]> wrote:
> Then I don't see how we decide when to clear a pointer at each
> level. Are there counters of how many entries are active in each
> table at all levels (pgd/pud/pmd/pte)?
No, there are no counters.
How it works is
On Tue, 22 Mar 2005 21:51:39 + (GMT)
Hugh Dickins <[EMAIL PROTECTED]> wrote:
> I still can't see what's wrong with the code that's already
> there. My brain is seizing up, I'm taking a break.
Ok, meanwhile I'll do a brain dump of what I think this
code should be doing.
Let's take an
On Tue, 22 Mar 2005 23:02:43 +0100
Adrian Bunk <[EMAIL PROTECTED]> wrote:
> The Coverity checker discovered that i never gets any value different
> from 0 assigned.
>
> I do not claim that this patch is correct, but if it isn't correct the
> bug is that i never gets assigned any value.
Hugh, I got tired of rebooting just to get address walking
traces :-) So I wrote a little simulator.
Basically, it's free_pgtables() with the page table pointer
stuff ripped out.
You run it like this:
./simulator vma_file
Where vma_file is a text file composed of lines of the form:
START
On Tue, 22 Mar 2005 19:36:46 + (GMT)
Hugh Dickins <[EMAIL PROTECTED]> wrote:
> I notice that although both i386 and sparc64 use pgtable-nopud.h, the
> i386 pud_clear does nothing at all and the sparc64 pud_clear resets to 0.
Aha! And ppc does as well via asm-generic/4level-fixup.h which is
On Tue, 22 Mar 2005 19:36:46 + (GMT)
Hugh Dickins <[EMAIL PROTECTED]> wrote:
> I notice that although both i386 and sparc64 use pgtable-nopud.h, the
> i386 pud_clear does nothing at all and the sparc64 pud_clear resets to 0.
This was a dead end. I386 doesn't do anything with pud_clear() in
On Tue, 22 Mar 2005 11:21:25 -0800
"David S. Miller" <[EMAIL PROTECTED]> wrote:
> I'm trying to analyze my traces some more.
I think I see what's going wrong. On the first
address space traversal (free_pgd_range()), we
clear out the pgd, even though there are still
mo
On Tue, 22 Mar 2005 11:01:44 -0800
"David S. Miller" <[EMAIL PROTECTED]> wrote:
> Hmmm...
Thinking some more, one thing that is unique in the PPC64
and SPARC64 cases is that we are executing primarily
32-bit tasks and in such cases one PGD maps the entire
addre
Ok, here is a full dump of a free_pgtables() run that
fails to clear out all the PMD's.
It gets called with this VMA list (each entry is a
vm_start/vm_end tuple)
[0x0001:0x000a4000]
[0x000b2000:0x000b8000]
[0x000b8000:0x000de000]
[0x7000:0x7001a000]
[0x70028000:0x7002a000]
On Tue, 22 Mar 2005 16:37:09 + (GMT)
Hugh Dickins <[EMAIL PROTECTED]> wrote:
> If you and David could try the lame patch below,
> it'll at least give us a slight clue of where to be looking -
> every mm exiting with nr_ptes 1 means something different from
> every mm exiting with nr_ptes -1
On Tue, 22 Mar 2005 06:08:38 + (GMT)
Hugh Dickins <[EMAIL PROTECTED]> wrote:
> > It just wants the range of page tables liberated. I guess
> > essentially PMD_SIZE is the granularity.
>
> I _think_ that answer means that my current code is fine in this respect.
> But I'm not entirely
On Tue, 22 Mar 2005 05:47:13 + (GMT)
Hugh Dickins <[EMAIL PROTECTED]> wrote:
> > 1) start --> end straddles sparc64 address space hole
>
> That's an interesting remark. I hadn't noticed the signed long type.
> I believe the vma gathering in free_pgtables will have no problem with
> that,
On Tue, 22 Mar 2005 05:47:13 + (GMT)
Hugh Dickins [EMAIL PROTECTED] wrote:
1) start -- end straddles sparc64 address space hole
That's an interesting remark. I hadn't noticed the signed long type.
I believe the vma gathering in free_pgtables will have no problem with
that, but what
On Tue, 22 Mar 2005 06:08:38 + (GMT)
Hugh Dickins [EMAIL PROTECTED] wrote:
It just wants the range of page tables liberated. I guess
essentially PMD_SIZE is the granularity.
I _think_ that answer means that my current code is fine in this respect.
But I'm not entirely convinced.
On Tue, 22 Mar 2005 16:37:09 + (GMT)
Hugh Dickins [EMAIL PROTECTED] wrote:
If you and David could try the lame patch below,
it'll at least give us a slight clue of where to be looking -
every mm exiting with nr_ptes 1 means something different from
every mm exiting with nr_ptes -1 means
Ok, here is a full dump of a free_pgtables() run that
fails to clear out all the PMD's.
It gets called with this VMA list (each entry is a
vm_start/vm_end tuple)
[0x0001:0x000a4000]
[0x000b2000:0x000b8000]
[0x000b8000:0x000de000]
[0x7000:0x7001a000]
[0x70028000:0x7002a000]
On Tue, 22 Mar 2005 11:01:44 -0800
David S. Miller [EMAIL PROTECTED] wrote:
Hmmm...
Thinking some more, one thing that is unique in the PPC64
and SPARC64 cases is that we are executing primarily
32-bit tasks and in such cases one PGD maps the entire
address space.
I wonder if the free_pgtables
On Tue, 22 Mar 2005 11:21:25 -0800
David S. Miller [EMAIL PROTECTED] wrote:
I'm trying to analyze my traces some more.
I think I see what's going wrong. On the first
address space traversal (free_pgd_range()), we
clear out the pgd, even though there are still
more PMD's to process in that PGD
On Tue, 22 Mar 2005 19:36:46 + (GMT)
Hugh Dickins [EMAIL PROTECTED] wrote:
I notice that although both i386 and sparc64 use pgtable-nopud.h, the
i386 pud_clear does nothing at all and the sparc64 pud_clear resets to 0.
This was a dead end. I386 doesn't do anything with pud_clear() in
On Tue, 22 Mar 2005 19:36:46 + (GMT)
Hugh Dickins [EMAIL PROTECTED] wrote:
I notice that although both i386 and sparc64 use pgtable-nopud.h, the
i386 pud_clear does nothing at all and the sparc64 pud_clear resets to 0.
Aha! And ppc does as well via asm-generic/4level-fixup.h which is
Hugh, I got tired of rebooting just to get address walking
traces :-) So I wrote a little simulator.
Basically, it's free_pgtables() with the page table pointer
stuff ripped out.
You run it like this:
./simulator vma_file
Where vma_file is a text file composed of lines of the form:
START
On Tue, 22 Mar 2005 23:02:43 +0100
Adrian Bunk [EMAIL PROTECTED] wrote:
The Coverity checker discovered that i never gets any value different
from 0 assigned.
I do not claim that this patch is correct, but if it isn't correct the
bug is that i never gets assigned any value.
Indeed, 'i'
On Tue, 22 Mar 2005 21:51:39 + (GMT)
Hugh Dickins [EMAIL PROTECTED] wrote:
I still can't see what's wrong with the code that's already
there. My brain is seizing up, I'm taking a break.
Ok, meanwhile I'll do a brain dump of what I think this
code should be doing.
Let's take an example
On Tue, 22 Mar 2005 14:40:55 -0800
Luck, Tony [EMAIL PROTECTED] wrote:
Then I don't see how we decide when to clear a pointer at each
level. Are there counters of how many entries are active in each
table at all levels (pgd/pud/pmd/pte)?
No, there are no counters.
How it works is that it
On Wed, 23 Mar 2005 10:32:10 +1100
Nick Piggin [EMAIL PROTECTED] wrote:
I think David's on the right track - I think there's something a
bit wrong at the top. In my reply to Andrew in this thread I
posted a patch which may at least get things working...
We have to do the if (ceiling) check in
On Tue, 22 Mar 2005 15:53:08 -0800
Luck, Tony [EMAIL PROTECTED] wrote:
But I'm still confused by all the math on addr/end at each
level. Rounding up/down at each level should presumably be
based on the size of objects at the next level. So the pgd
code should round using PUD_MASK, pud
Ok, here are (finally, I've been debugging this so much purely
to see these things) some lmbench numbers with Hugh's base
patch on sparc64.
Ignore my previous comments about shell performance getting
worse, it's some difference that makes things run more slowly
in single user mode compared to a
Ok, this patch, on top of Hugh's original freepgt patch, gets
me a working system. It includes Hugh's bug fix, plus the
ceiling masking roll-over fix of mine.
It should get ppc working too, I bet.
--- mm/memory.c.hugh2005-03-22 16:01:07.0 -0800
+++ mm/memory.c 2005-03-22
On Wed, 23 Mar 2005 11:19:38 +1100
Nick Piggin [EMAIL PROTECTED] wrote:
dramatically, shell performance is way down on sparc64.
I'll post before and after numbers in a bit. Note, this is
just with Hugh's base patch plus bug fixes.
That's interesting. The only extra stuff Hugh's
On Tue, 22 Mar 2005 17:10:13 -0800
Andrew Morton [EMAIL PROTECTED] wrote:
Hugh Dickins [EMAIL PROTECTED] wrote:
On Tue, 22 Mar 2005, Luck, Tony wrote:
But I'm still confused by all the math on addr/end at each
level.
You think the rest of us are not ;-?
umm, given the
On Wed, 23 Mar 2005 00:51:02 + (GMT)
Hugh Dickins [EMAIL PROTECTED] wrote:
This actual example helped to focus my mind a lot, thank you.
No problem, I needed to work through specific examples
to see things clearly too.
and things seem to behave. I'll try to analyze things
further and
On Wed, 23 Mar 2005 13:10:42 +1100
Nick Piggin [EMAIL PROTECTED] wrote:
The ugly thing you get with an inclusive ceiling is that your masking
becomes more difficult I think.
Good point.
I might try to attack this from another angle and see if I can come up
with something.
Great, let me
On Thu, 17 Mar 2005 20:34:05 +0100 (CET)
Jesper Juhl [EMAIL PROTECTED] wrote:
kfree() handles NULL pointers just fine, checking first is pointless.
Signed-off-by: Jesper Juhl [EMAIL PROTECTED]
Applied, thanks Jesper.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
On Fri, 18 Mar 2005 15:59:02 -0800
Jean Tourrilhes [EMAIL PROTECTED] wrote:
A pretty big and tedious patch that mostly rename IrDA debug
macros, plus a few other tiny fixes. Has been on my web pages for a
long while, tested and rediff'd on 2.6.12-rc1. I would be grateful if
you could
On Tue, 22 Mar 2005 15:14:54 +1100
Nick Piggin <[EMAIL PROTECTED]> wrote:
> Question, Dave: flush_tlb_pgtables after Hugh's patch is also
> possibly not being called with enough range to cover all page
> tables that have been freed.
>
> For example, you may have a single page (start,end) address
On Mon, 21 Mar 2005 14:31:36 -0800
"Luck, Tony" <[EMAIL PROTECTED]> wrote:
> Builds clean and boots on ia64.
>
> I haven't tried any hugetlb operations on it though.
It works on ia64 because it doesn't actually do anything
in flush_tlb_pgtables(), I bet.
Hugh, I know the exact trigger case,
On Mon, 21 Mar 2005 20:52:44 + (GMT)
Hugh Dickins <[EMAIL PROTECTED]> wrote:
Hugh, I'm getting some problems on sparc64 here:
> +static inline void free_pgd_range(struct mmu_gather *tlb,
> + unsigned long addr, unsigned long end,
> + unsigned long
On Mon, 21 Mar 2005 20:52:44 + (GMT)
Hugh Dickins [EMAIL PROTECTED] wrote:
Hugh, I'm getting some problems on sparc64 here:
+static inline void free_pgd_range(struct mmu_gather *tlb,
+ unsigned long addr, unsigned long end,
+ unsigned long floor,
On Mon, 21 Mar 2005 14:31:36 -0800
Luck, Tony [EMAIL PROTECTED] wrote:
Builds clean and boots on ia64.
I haven't tried any hugetlb operations on it though.
It works on ia64 because it doesn't actually do anything
in flush_tlb_pgtables(), I bet.
Hugh, I know the exact trigger case, it's
On Sat, 19 Mar 2005 12:30:05 -0800
David Mosberger <[EMAIL PROTECTED]> wrote:
> I agree about your concern about cost. Accessing the page_map is
> expensive (integer division + memory access) and we have to do that in
> order to find out if the page is i-cache clean.
First, it's a multiply by
On Sat, 19 Mar 2005 12:30:05 -0800
David Mosberger [EMAIL PROTECTED] wrote:
I agree about your concern about cost. Accessing the page_map is
expensive (integer division + memory access) and we have to do that in
order to find out if the page is i-cache clean.
First, it's a multiply by
This is way overkill I think.
Take a look at set_pte_at(). You get the "mm", the
virtual address, the pte pointer, and the new pte value.
What else could you possibly need to track stuff like this
and react appropriately? :-)
It is even an argument for batched TLB processing on ia64.
It
On Fri, 18 Mar 2005 11:25:45 -0800
"Randy.Dunlap" <[EMAIL PROTECTED]> wrote:
> The sparc32 & sparc64 code needs live testing.
These patches look great Randy. I think they should go in.
If sparc explodes, I'll clean up the mess. Any problem which
crops up should not be difficult to solve.
-
To
On Fri, 18 Mar 2005 19:25:46 +0100
Sven Henkel <[EMAIL PROTECTED]> wrote:
> This patch fixes an alignment-problem in tun_get_user: Only
> ethernet-frames need to be headed by 2 bytes (due to their size of 14
> bytes), IP-frames should not be touched. The patch changes
> tun_get_user to reserve 2
On Fri, 18 Mar 2005 18:57:32 +0100
Sven Henkel <[EMAIL PROTECTED]> wrote:
> The udp-packet constructed in netpoll_send_udp should be aligned
> to avoid alignment-traps on some platforms. The patch applies to
> vanilla 2.6.11.2.
Patch applied, thanks Sven.
Please post networking patches in the
On Fri, 18 Mar 2005 18:57:32 +0100
Sven Henkel [EMAIL PROTECTED] wrote:
The udp-packet constructed in netpoll_send_udp should be aligned
to avoid alignment-traps on some platforms. The patch applies to
vanilla 2.6.11.2.
Patch applied, thanks Sven.
Please post networking patches in the future
On Fri, 18 Mar 2005 19:25:46 +0100
Sven Henkel [EMAIL PROTECTED] wrote:
This patch fixes an alignment-problem in tun_get_user: Only
ethernet-frames need to be headed by 2 bytes (due to their size of 14
bytes), IP-frames should not be touched. The patch changes
tun_get_user to reserve 2 bytes
On Fri, 18 Mar 2005 11:25:45 -0800
Randy.Dunlap [EMAIL PROTECTED] wrote:
The sparc32 sparc64 code needs live testing.
These patches look great Randy. I think they should go in.
If sparc explodes, I'll clean up the mess. Any problem which
crops up should not be difficult to solve.
-
To
This is way overkill I think.
Take a look at set_pte_at(). You get the mm, the
virtual address, the pte pointer, and the new pte value.
What else could you possibly need to track stuff like this
and react appropriately? :-)
It is even an argument for batched TLB processing on ia64.
It
On Thu, 17 Mar 2005 02:08:21 +0100
Adrian Bunk <[EMAIL PROTECTED]> wrote:
> inet_peer_unused_tailp might be referenced from other files via
> inetpeer.h, but inet_peer_unused_head isn't referenced directly from
> other files.
I misread your patch, I thought you were marking both
as static. My
401 - 500 of 1880 matches
Mail list logo
