- 05 Mar, 2005 40 commits
-
-
Andrew Morton authored
I cannot find a version of binutils which doesn't either do arch/ppc64/kernel/vdso32/gettimeofday.S: Assembler messages: arch/ppc64/kernel/vdso32/gettimeofday.S:33: Error: syntax error; found `@' but expected `,' or arch/ppc64/kernel/vdso32/gettimeofday.S: Assembler messages: arch/ppc64/kernel/vdso32/gettimeofday.S:33: Internal error, aborting at ../../gas/config/tc-ppc.c line 2658 in md_assemble Signed-off-by:
Andrew Morton <akpm@osdl.org> Signed-off-by:
Linus Torvalds <torvalds@osdl.org>
-
Benjamin Herrenschmidt authored
This patch adds to the ppc64 kernel a virtual .so (vDSO) that is mapped into every process space, similar to the x86 vsyscall page. However, the implementation is very different (and doesn't use the gate area mecanism). Actually, it contains two implementations, a 32 bits and a 64 bits one. These vDSO's are currently mapped at 0x100000 (+1Mb) when possible (when a process load section isn't already there). In the future, we can randomize that address, or even imagine having a special phdr entry letting apps that wnat finer control over their address space to put it elsewhere (or not at all). The implementation adds a hook to binfmt_elf to let the architecture add a real VMA to the process space instead of using the gate area mecanism. This mecanism wasn't very suitable for ppc, we couldn't just "shove" PTE entries mapping kernel addresses into userland without expensive changes to our hash table management. Instead, I made the vDSO be a normal VMA which, additionally, means it supports copy-on-write semantics if made writable via ptrace/mprotect, thus allowing breakpoints in the vDSO code. The current implementation of the vDSOs contain the signal trampolines with appropriate DWARF informations, which enable us to use non-executable stacks (patches to come later) along with a few more functions that we hope glibc will soon make good use of (this is the "hard" part now :) Note that the symbols exposed by the vDSO aren't "normal" function symbols, apps can't be expected to link against them directly, the vDSO's are both seen as if they were linked at 0 and the symbols just contain offsets to the various functions. This is done on purpose to avoid a relocation step (ppc64 functions normally have descriptors with abs addresses in them). When glibc uses those functions, it's expected to use it's own trampolines that know how to reach them. In some cases, the vDSO contains several versions of a given function (for various CPUs), the kernel will "patch" the symbol table at boot to make it point to the appropriate one transparently. What is currently implemented is: - int __kernel_gettimeofday(struct timeval *tv, struct timezone *tz); This is a fully userland implementation of gettimeofday, with no barriers and no locks, and providing 100% equivalent results to the syscall version - void __kernel_sync_dicache(unsigned long start, unsigned long end) This function sync's the data and instruction caches (for making data executable), it is expected that userland loaders use this instead of doing it themselves, as the kernel will provide optimized versions for the current CPU. Currently, the vDSO procides a full one for all CPUs prior to POWER5 and a nop one for POWER5 which implements hardware snooping at the L1 level. In the future, an intermediate implementation may be done for the POWER4 and 970 which don't need the "dcbst" loop (the L1D cache is write-through on those). - void *__kernel_get_syscall_map(unsigned int *syscall_count); Returns a pointer to a map of implemented syscalls on the currently running kernel. The map is agnostic to the size of "long", unlike kernel bitops, it stores bits from top to bottom so that memory actually contains a linear bitmap check for syscall N by testing bit (0x80000000 >> (N & 0x1f)) of * 32 bits int at N >> 5. Note about backward compatibility issues: A bug in the ppc64 libgcc unwinder makes it unable to unwind stacks properly accross signals if the signal trampoline isn't on the stack. This has been fixed in CVS for gcc 4.0 and will be soon on the stable branch, but the problem exist will all currently used versions. That means that until glibc gets the patch to enable it's use of the vDSO symbols for the DWARF unwinder (rather trivial patch that will be pushed to glibc CVS soon hopefully), unwinding from a signal handler will not work for 64 bits applications. I consider this as a non-issue though as a patch is about to be produced, which can easily get pushed to "live" distros like debian, gentoo, fedora, etc... soon enough (it breaks compatilbity with kernels below 2.4.20 unfortunately as our signal stack layout changed, crap crap crap), as there are few 64 bits applications out there (expect gentoo), as it's only really an issue with C++ code relying on throwing exceptions out of signal handlers (extremely rare it seems), and as "release" distros like SLES or RHEL will probably have the vDSO enabled glibc _and_ the unwinder fix by the time they release a version with a 2.6.11 or 2.6.12 kernel anyway :) So far, I yet have to see an app failing because of that... Finally, many many many thanks to Alan Modra for writing the DWARF information of the signal handlers and debugging the libgcc issues ! Signed-off-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by:
-
Stephen Rothwell authored
This patch just moves as many as possible EXPORT_SYMBOL()s from arch/ppc64/kernel/ppc_ksyms.c to where the symbols are defined. This has been compiled on pSeries, iSeries and pmac. Signed-off-by:
Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by:
-
Olaf Hering authored
Update several ppc64 defconfigs. Signed-off-by:
-
Benjamin Herrenschmidt authored
The "systemcfg" data structure in the ppc64 kernel is something that used to be defined to be at a hard-coded page number in the kernel image. This is not necessary (at least not any more) and is a possible problem with future developements. This patch removes that constraint, which also simplifies various bits of assembly in head.S that were dealing with it. This is the first step of a deeper cleanup of systemcfg definition of usage (and ultimately removal in it's current incarnation). Signed-off-by:
-
Paul Mackerras authored
POWER5 machines have a per-hardware-thread register which counts at a rate which is proportional to the percentage of cycles on which the cpu dispatches an instruction for this thread (if the thread gets all the dispatch cycles it counts at the same rate as the timebase register). This register is also context-switched by the hypervisor. Thus it gives a fine-grained measure of the actual cpu usage by the thread over time. This patch adds code to read this register every timer interrupt and on every context switch. The total over all virtual processors is available through the existing /proc/ppc64/lparcfg file, giving a way to measure the total cpu usage over the whole partition. Signed-off-by:
Manish Ahuja <ahuja@austin.ibm.com> Signed-off-by:
Paul Mackerras <paulus@samba.org> Signed-off-by:
-
Olaf Hering authored
The pseries nvram driver started probably as a copy of nvram.c. These includes are not needed to build it. Signed-off-by:
Olaf Hering <olh@suse.de> Signed-off-by:
-
Kumar Gala authored
Patch adds support for the initial PowerQUICC II Pro processors (MPC8343/E, MPC8347/E, and MPC8349/E) and the first reference platform (MPC834x SYS) from Freescale. The initial support is limited to existing drivers that overlap with the MPC85xx subarch (ethernet, I2C, uart). Signed-off-by:
Kumar Gala <kumar.gala@freescale.com> Signed-off-by:
-
Kumar Gala authored
This patch fixes a trival bug in the CRITICAL_EXCEPTION macro Signed-off-by:
Takeharu KATO <kato.takeharu@jp.fujitsu.com> Signed-off-by:
-
Kumar Gala authored
This patch makes the MPC8555 CDS system utilize the DS1553 RTC/NVRAM. Signed-off-by:
-
Kumar Gala authored
This patch adds support for the Dallas 1553 RTC/NVRAM. Signed-off-by:
-
Matt Porter authored
This patch adds support for OpenBios on Ebony, as Matt Porter has suggested. It will provide same functionality as the pibs extension for Luan and Ocotea. Signed-off-by:
Gerhard Jaeger <gjaeger@sysgo.com> Signed-off-by:
Matt Porter <mporter@kernel.crashing.org> Signed-off-by:
-
Mark A. Greer authored
Add mv64x60 GPP IO pin/IRQ register definitions Signed-off-by:
James Chapman <jchapman@katalix.com> Signed-off-by:
Mark A. Greer <mgreer@mvista.com> Signed-off-by:
-
Mark A. Greer authored
Add support for non-zero irq base to mv64360_pic code. - Fix mv64360 pic code to handle non-zero mv64x60_irq_base - Cleanup mv64360 entries in /proc/interrupts Signed-off-by:
-
Kumar Gala authored
Removes explicit defines for SVR_85xx and use the information in the ppc_sys_specs table in platform code. Changed the ppc_sys_name strings to be a bit more generic so we have a bit more flexilibity when we display them. Signed-off-by:
-
Kumar Gala authored
Fix whitespace in arch/ppc/platforms/85xx/mpc85xx_cds_common.c Signed-off-by:
-
Benjamin Herrenschmidt authored
This patch fix bogus types in the definition of __cmpxchg_u32() on ppc32. Signed-off-by:
-
Mark A. Greer authored
This patch fixes the incorrect definition of a macro that sets the transmit parity to even on a cpm uart device. Signed-off-by:
Mark A. Greer <mgreer@mista.com> Signed-off-by:
-
Eugene Surovegin authored
This patch fixes bug in PPC4xx disable_irq implementation. We need to ACK parent UIC to prevent false triggering in case IRQ we just disabled was already pending. Signed-off-by:
Eugene Surovegin <ebs@ebshome.net> Signed-off-by:
-
Eugene Surovegin authored
This patch fixes whitespace in PPC4xx PIC driver. Signed-off-by:
-
Matt Porter authored
Move the code that informs the kernel if the particular interrupt is edge triggered or level sensitive from the board specific file to a "CONFIG_VIRTEX_II_PRO-specific" file. Using old IRQ numbering in that code is also fixed. Signed-off-by:
Andrei Konovalov <akonovalov@ru.mvista.com> Signed-off-by:
-
Mark A. Greer authored
- Adapt Katana to the new names used by the ethernet driver. - Remove SRAM allocation code for mv643xx_enet until it's had more review. Signed-off-by:
Dale Farnsworth <dale@farnsworth.org> Signed-off-by:
-
Mark A. Greer authored
- Adds MTD support for the soldered FLASH - Adds cmdline parsing - Turns on the Blue LED when the system is halted - Moves some of the device window left by the firmware to proper alignments - Handles possibility of different frequencies for TCLK & SysCLK in 64460 - Misc. code clean up Signed-off-by:
-
Olaf Hering authored
enable drm/agp, cpufreq, pppoe and new pccard option Signed-off-by:
-
Mark A. Greer authored
The gt64260 looks at the highest 20 bits while the mv64[34]60 looks at only the highest 16 bits when determining the base address for the bridge's registers. This patch adds support for both. Signed-off-by:
Nate Case <ncase@xes-inc.com> Signed-off-by:
-
Tom Rini authored
This changes how the ppc32 'checkbin' target works. Previously we did all of the tests using variables which would be evaluated for any and every make target. This meant that 'make tags' for example would leave behind a '.tmp_gas_check' file even though we didn't actually compile up anything, and would get in the way of diffs. By moving all of this logic directly into the 'checkbin' target, we only test gcc/gas versions when we're going to compile. Signed-off-by:
Tom Rini <trini@kernel.crashing.org> Signed-off-by:
-
Olof Johansson authored
Abstract most manual mask checks of cpu_features with cpu_has_feature() Signed-off-by:
Olof Johansson <olof@austin.ibm.com> Signed-off-by:
-
bill.irwin@oracle.com authored
Convert mapping->tree_lock to an rwlock. with: dd if=/dev/zero of=foo bs=1 count=2M 0.80s user 4.15s system 99% cpu 4.961 total dd if=/dev/zero of=foo bs=1 count=2M 0.73s user 4.26s system 100% cpu 4.987 total dd if=/dev/zero of=foo bs=1 count=2M 0.79s user 4.25s system 100% cpu 5.034 total dd if=foo of=/dev/null bs=1 0.80s user 3.12s system 99% cpu 3.928 total dd if=foo of=/dev/null bs=1 0.77s user 3.15s system 100% cpu 3.914 total dd if=foo of=/dev/null bs=1 0.92s user 3.02s system 100% cpu 3.935 total (3.926: 1.87 usecs) without: dd if=/dev/zero of=foo bs=1 count=2M 0.85s user 3.92s system 99% cpu 4.780 total dd if=/dev/zero of=foo bs=1 count=2M 0.78s user 4.02s system 100% cpu 4.789 total dd if=/dev/zero of=foo bs=1 count=2M 0.82s user 3.94s system 99% cpu 4.763 total dd if=/dev/zero of=foo bs=1 count=2M 0.71s user 4.10s system 99% cpu 4.810 tota dd if=foo of=/dev/null bs=1 0.76s user 2.68s system 100% cpu 3.438 total dd if=foo of=/dev/null bs=1 0.74s user 2.72s system 99% cpu 3.465 total dd if=foo of=/dev/null bs=1 0.67s user 2.82s system 100% cpu 3.489 total dd if=foo of=/dev/null bs=1 0.70s user 2.62s system 99% cpu 3.326 total (3.430: 1.635 usecs) So on a P4, the additional cost of the rwlock is ~240 nsecs for a one-byte-write(). On the other hand: From: Peter Chubb <peterc@gelato.unsw.edu.au> As part of the Gelato scalability focus group, we've been running OSDL's Re-AIM7 benchmark with an I/O intensive load with varying numbers of processors. The current kernel shows severe contention on the tree_lock in the address space structure when running on tmpfs or ext2 on a RAM disk. Lockstat output for a 12-way: SPINLOCKS HOLD WAIT UTIL CON MEAN( MAX ) MEAN( MAX )(% CPU) TOTAL NOWAIT SPIN RJECT NAME 5.5% 0.4us(3177us) 28us( 20ms)(44.2%) 131821954 94.5% 5.5% 0.00% *TOTAL* 72.3% 13.1% 0.5us( 9.5us) 29us( 20ms)(42.5%) 50542055 86.9% 13.1% 0% find_lock_page+0x30 23.8% 0% 385us(3177us) 0us 23235 100% 0% 0% exit_mmap+0x50 11.5% 0.82% 0.1us( 101us) 17us(5670us)( 1.6%) 50665658 99.2% 0.82% 0% dnotify_parent+0x70 Replacing the spinlock with a multi-reader lock fixes this problem, without unduly affecting anything else. Here are the benchmark results (jobs per minute at a 50-client level, average of 5 runs, standard deviation in parens) on an HP Olympia with 3 cells, 12 processors, and dnotify turned off (after this spinlock, the spinlock in dnotify_parent is the worst contended for this workload). tmpfs............... ext2............... #CPUs spinlock rwlock spinlock rwlock 1 7556(15) 7588(17) +0.42% 3744(20) 3791(16) +1.25% 2 13743(31) 13791(33) +0.35% 6405(30) 6413(24) +0.12% 4 23334(111) 22881(154) -2% 9648(51) 9595(50) -0.55% 8 33580(240) 36163(190) +7.7% 13183(63) 13070(68) -0.85% 12 28748(170) 44064(238)+53% 12681(49) 14504(105)+14% And on a pentium3 single processsor: 1 4177(4) 4169(2) -0.2% 3811(4) 3820(3) +0.23% I'm not sure what's happening in the 4-processor case. The important thing to note is that with a spinlock, the benchmark shows worse performance for a 12 than for an 8-way box; with the patch, the 12 way performs better, as expected. We've done some runs with 16-way as well; without the patch below, the 16-way performs worse than the 12-way. It's a tricky tradeoff, but large-smp is hurt a lot more by the spinlocks than small-smp is by the rwlocks. And I don't think we really want to implement compile-time either-or-locks. Signed-off-by: -
Zach Brown authored
Now that we're only invalidating the pages that intersected a direct IO write we might as well only unmap the intersecting bytes as well. This passed a light fsx load with page cache, direct, and mmap IO. Signed-off-by:
Zach Brown <zach.brown@oracle.com> Signed-off-by:
-
Zach Brown authored
This adds filemap_write_and_wait_range(mapping, lstart, lend) which starts writeback and waits on a range of pages. We call this from __blkdev_direct_IO with just the range that is going to be read by the direct_IO read. It was lightly tested with fsx and ext3 and passed. Signed-off-by:
-
Zach Brown authored
Presently we invalidate all of a file's pages when writing to any part of that file with direct-IO. After a direct IO write only invalidate the pages that the write intersected. invalidate_inode_pages2_range(mapping, pgoff start, pgoff end) is added and called from generic_file_direct_IO(). While we're in there, invalidate_inode_pages2() was calling unmap_mapping_range() with the wrong convention in the single page case. It was providing the byte offset of the final page rather than the length of the hole being unmapped. This is also fixed. This was lightly tested with a 10k op fsx run with O_DIRECT on a 16MB file in ext3 on a junky old IDE drive. Totaling vmstat columns of blocks read and written during the runs shows that read traffic drops significantly. The run time seems to have gone down a little. Two runs before the patch gave the following user/real/sys times and total blocks in and out: 0m28.029s 0m20.093s 0m3.166s 16673 125107 0m27.949s 0m20.068s 0m3.227s 18426 126094 and after the patch: 0m26.775s 0m19.996s 0m3.060s 3505 124982 0m26.856s 0m19.935s 0m3.052s 3505 125279 akpm: - Don't look up more pages than we're going to use - Don't test page->index until we've locked the page - Check for the cursor wrapping at the end of the mapping. Signed-off-by:
-
Christoph Lameter authored
In the 2.6.11 development cycle function calls have been added to lots of hot vm paths to do accounting. I think these should not go into the final 2.6.1 release because these statistics can be collected in a different way that does not require the updating of counters from frequently used vm code paths and is consistent with the methods use elsewhere in the kernel to obtain statistics. These function calls are acct_update_integrals -> Account for processes based on stime changes update_mem_hiwater -> takes rss and total_vm hiwater marks. acct_update_integrals is only useful to call if stime changes otherwise it will simply return. It is therefore best to relocate the function call to acct_update_integral into the function that updates stime which is account_system_time and remove it from the vm code paths. update_mem_hiwater finds the rss hiwater mark. We call that from timer context as well. This means that processes' high-water marks are now sampled statistically, at timer-interrupt time rather than deterministically. This may or may not be a problem.. This means that the rss limit is not always updated if rss is increased and thus not as accurate. But the benefit is that the rss checks do no pollute the vm paths and that it is consistent with the rss limit check. The following patch removes acct_update_integrals and update_mem_hiwater from the hot vm paths. Signed-off-by:
Christoph Lameter <clameter@sgi.com> From: Jay Lan <jlan@sgi.com> The new "move-accounting-function-calls-out-of-critical-vm-code-paths" patch in 2.6.11-rc3-mm2 was different from the code i tested. In particular, it mistakenly dropped the accounting routine calls in fs/exec.c. The calls in do_execve() are needed to properly initialize accounting fields. Specifically, the tsk->acct_stimexpd needs to be initialized to tsk->stime. I have discussed this with Christoph Lameter and he gave me full blessings to bring the calls back. Signed-off-by:
Jay Lan <jlan@sgi.com> Signed-off-by:
-
Arjan van de Ven authored
In addition to randomisation of the stack pointer within the stack, the stack itself should be randomized too. We need both approaches, we can only randomize the stack itself in pagesize increments. However randomizing large ranges with the stackpointer runs into the situation where a huge chunk of the stack rlimit is used by the randomisation; this is undesirable so we need to do both. Signed-off-by:
Arjan van de Ven <arjan@infradead.org> Signed-off-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
-
Arjan van de Ven authored
Introduce a personality that disables randomisation, so that users can use setarch and related commands to run specific applications without randomisation. Signed-off-by:
-
Arjan van de Ven authored
Signed-off-by:
-
Arjan van de Ven authored
The patch below randomizes the starting point of the mmap area. This has the effect that all non-prelinked shared libaries and all bigger malloc()s will be randomized between various invocations of the binary. Prelinked binaries get a address-hint from ld.so in their mmap and are thus exempt from this randomisation, in order to not break the prelink advantage. The randomisation range is 1 megabyte (this is bigger than the stack randomisation since the stack randomisation only needs 16 bytes alignment while the mmap needs page alignment, a 64kb range would not have given enough entropy to be effective) Signed-off-by:
-
Arjan van de Ven authored
The patch below replaces the existing 8Kb randomisation of the userspace stack pointer (which is currently only done for Hyperthreaded P-IVs) with a more general randomisation over a 64Kb range. 64Kb is not a lot, but it's a start and once the dust settles we can increase this value to a more agressive value. Signed-off-by:
-
Arjan van de Ven authored
Even though there is a global flag to disable randomisation, it's useful to have a per process flag too; the patch below introduces this per process flag and automatically sets it for "new" binaries. Eventually we will want to tie this to the legacy-va-space personality Signed-off-by:
-
Arjan van de Ven authored
The patch below introduces get_random_int() and randomize_range(), two helpers used in later patches in the series. get_random_int() shares the tcp/ip random number stuff so the CONFIG_INET ifdef needs to move slightly, and to reduce the damange due to that, secure_ip_id() needs to move inside random.c From: Frank Sorenson <frank@tuxrocks.com> Acked-By:
Jeff Dike <jdike@addtoit.com> The stack randomization patches that went into 2.6.11-rc3-mm1 broke compilation of ARCH=um. This patch fixes compiling by adding arch_align_stack back in. Signed-off-by:
Frank Sorenson <frank@tuxrocks.com> Signed-off-by:
-
Arjan van de Ven authored
This first patch of the series introduces a sysctl (default off) that enables/disables the randomisation feature globally. Since randomisation may make it harder to debug really tricky situations (reproducability goes down), the sysadmin needs a way to disable it globally. Signed-off-by:
-
