Ok, I'll cook a patch today.
Let's make it tomorrow :-( Got delayed by other urgent things
Cheers,
Ben.
-
To unsubscribe from this list: send the line unsubscribe sparclinux in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, 2007-05-14 at 20:19 +0100, Hugh Dickins wrote:
On Thu, 10 May 2007, David Miller wrote:
We never seemed to reach completion here?
Well, I'm waiting for other people comments too... as I said earlier,
I'm not too fan of burrying the update_mmu_cache() inside
We never seemed to reach completion here?
Well, I'm waiting for other people comments too... as I said earlier,
I'm not too fan of burrying the update_mmu_cache() inside
ptep_set_access_flags(), but perhaps we could remove the whole logic of
reading the old PTE comparing it, and instead have
From: Benjamin Herrenschmidt [EMAIL PROTECTED]
Date: Thu, 10 May 2007 16:29:43 +1000
We never seemed to reach completion here?
Well, I'm waiting for other people comments too... as I said earlier,
I'm not too fan of burrying the update_mmu_cache() inside
ptep_set_access_flags(), but
Hi Ben,
Is it worth formally sending in either of my patches or does more work
need to be done first?
If you would like me to test any changes, it takes me app. 2 hours to
cross-compile a sparc kernel for my sun4c. I use my sparc system as a
diskless client with a very minimal setup to alow
On Wed, 2007-05-09 at 20:44 +0100, Mark Fortescue wrote:
Hi Ben,
Is it worth formally sending in either of my patches or does more work
need to be done first?
Sorry, I've been busy with other things...
What do other thing about it ? Having update_mmu_cache() call buried
inside the
On Tue, 1 May 2007, Benjamin Herrenschmidt wrote:
At present, update_mmu_cache() and lazy_mmu_prot_update() are always
called when ptep_set_access_flags() is called so why not move them into
ptep_set_access_flags() and change ptep_set_access_flags() to have an
additional boolean parameter
I have attached a patch (so pine does not mangle it) for linux-2.6.20.9.
Is this what you had in mind?
For linux-2.6.21, more work will be needed as it has more code calling
ptep_set_access_flags.
I'm not 100% sure we need the 'update' argument... we can remove the
whole old_entry,
On Wed, 2 May 2007, Benjamin Herrenschmidt wrote:
I have attached a patch (so pine does not mangle it) for linux-2.6.20.9.
Is this what you had in mind?
For linux-2.6.21, more work will be needed as it has more code calling
ptep_set_access_flags.
I'm not 100% sure we need the 'update'
Hi all,
I have tracked down a failure to successfully load/run the init task on my
Sparcstation 1 clone (SS1) and Sparcstation 2 (SS2), sparc32 sun4c
systems, to a patch:
commit 1a44e149084d772a1bcf4cdbdde8a013a8a1cfde.
[PATCH] .text page fault SMP scalability optimization
Removing this
On Mon, 30 Apr 2007 22:36:27 +0100 (BST)
Mark Fortescue [EMAIL PROTECTED] wrote:
Hi all,
I have tracked down a failure to successfully load/run the init task on my
Sparcstation 1 clone (SS1) and Sparcstation 2 (SS2), sparc32 sun4c
systems, to a patch:
commit
From: Andrew Morton [EMAIL PROTECTED]
Date: Mon, 30 Apr 2007 14:54:14 -0700
On Mon, 30 Apr 2007 22:36:27 +0100 (BST)
Mark Fortescue [EMAIL PROTECTED] wrote:
Hi all,
I have tracked down a failure to successfully load/run the init task on my
Sparcstation 1 clone (SS1) and Sparcstation
Hi David,
Is this just sun4c or does it affect other sparc32 architectures.
Regards
Mark Fortescue.
On Mon, 30 Apr 2007, David Miller wrote:
From: Andrew Morton [EMAIL PROTECTED]
Date: Mon, 30 Apr 2007 14:54:14 -0700
On Mon, 30 Apr 2007 22:36:27 +0100 (BST)
Mark Fortescue [EMAIL
From: Mark Fortescue [EMAIL PROTECTED]
Date: Mon, 30 Apr 2007 23:33:13 +0100 (BST)
Is this just sun4c or does it affect other sparc32 architectures.
Only sun4c.
srmmu's update_mmu_cache() is basically a NOP.
-
To unsubscribe from this list: send the line unsubscribe sparclinux in
the body of a
Interesting - thanks for working that out. Let's keep linux-mm on cc
please.
You can't elide the update_mmu_cache() call on sun4c because that will
miss some critical TLB setups which are performed there.
The sun4c TLB has two tiers of entries:
1) segment maps, these hold ptes for
From: Benjamin Herrenschmidt [EMAIL PROTECTED]
Date: Tue, 01 May 2007 10:00:19 +1000
Interesting - thanks for working that out. Let's keep linux-mm on cc
please.
You can't elide the update_mmu_cache() call on sun4c because that will
miss some critical TLB setups which are
At present, update_mmu_cache() and lazy_mmu_prot_update() are always
called when ptep_set_access_flags() is called so why not move them into
ptep_set_access_flags() and change ptep_set_access_flags() to have an
additional boolean parameter (__update) that would when set, cause
Hi,
Does any one have or know of a good reference that would help me in
identifing the cause of a CPU soft lockup that apears to be related to
changes in the vertual memory handling between these two versions of the
kernel?
My SS1 clone and SS2 are both unable to run much more than sash due
On Sun, 2007-04-29 at 14:02 +0100, Mark Fortescue wrote:
Hi,
Does any one have or know of a good reference that would help me in
identifing the cause of a CPU soft lockup that apears to be related to
changes in the vertual memory handling between these two versions of the
kernel?
Have
19 matches
Mail list logo
