aboutsummaryrefslogtreecommitdiffstats
path: root/arch/sparc64/mm (follow)
AgeCommit message (Collapse)AuthorFilesLines
2005-07-27[SPARC64]: Fix ugly dependency on NR_CPUS being a power-of-2.David S. Miller1-6/+17
The page->flags D-cache dirty state tracking depended upon NR_CPUS being a power-of-2 via it's "NR_CPUS - 1" masking. Fix that to use a fixed (256 - 1) mask as that is the limit imposed by thread_info->cpu which is a "u8". Finally, add a compile time check that NR_CPUS is not greater than 256. Signed-off-by: David S. Miller <davem@davemloft.net>
2005-07-10[SPARC64]: Kill ancient and unused SYSCALL_TRACING debugging code.David S. Miller1-16/+0
Signed-off-by: David S. Miller <davem@davemloft.net>
2005-07-05[SPARC64]: Fix UltraSPARC-III fallout from membar changes.David S. Miller1-2/+3
The membar changes made the size of __cheetah_flush_tlb_pending grow by one instruction, but the boot-time code patching was not updated to match. Signed-off-by: David S. Miller <davem@davemloft.net>
2005-06-27[SPARC64]: Avoid membar instructions in delay slots.David S. Miller2-3/+6
In particular, avoid membar instructions in the delay slot of a jmpl instruction. UltraSPARC-I, II, IIi, and IIe have a bug, documented in the UltraSPARC-IIi User's Manual, Appendix K, Erratum 51 The long and short of it is that if the IMU unit misses on a branch or jmpl, and there is a store buffer synchronizing membar in the delay slot, the chip can stop fetching instructions. If interrupts are enabled or some other trap is enabled, the chip will unwedge itself, but performance will suffer. We already had a workaround for this bug in a few spots, but it's better to have the entire tree sanitized for this rule. Signed-off-by: David S. Miller <davem@davemloft.net>
2005-06-21[PATCH] Hugepage consolidationDavid Gibson1-171/+24
A lot of the code in arch/*/mm/hugetlbpage.c is quite similar. This patch attempts to consolidate a lot of the code across the arch's, putting the combined version in mm/hugetlb.c. There are a couple of uglyish hacks in order to covert all the hugepage archs, but the result is a very large reduction in the total amount of code. It also means things like hugepage lazy allocation could be implemented in one place, instead of six. Tested, at least a little, on ppc64, i386 and x86_64. Notes: - this patch changes the meaning of set_huge_pte() to be more analagous to set_pte() - does SH4 need s special huge_ptep_get_and_clear()?? Acked-by: William Lee Irwin <wli@holomorphy.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-05[SPARC64]: Kill useless __pte_alloc_one_kernel indirectionChristoph Hellwig1-1/+1
warning: untested, but it there's not too much chance for screwups Signed-off-by: David S. Miller <davem@davemloft.net>
2005-04-17[PATCH] sparc64: Do not flush dcache for ZERO_PAGE.David S. Miller1-4/+15
This case actually can get exercised a lot during an ELF coredump of a process which contains a lot of non-COW'd anonymous pages. GDB has this test case which in partiaular creates near terabyte process full of ZERO_PAGEes. It takes forever to just walk through the page tables because of all of these spurious cache flushes on sparc64. With this change it takes only a second or so. Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16Linux-2.6.12-rc2Linus Torvalds8-0/+3612
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!