- 12 Oct, 2009 2 commits
-
-
Tejun Heo authored
-
Tejun Heo authored
Fix the following two compile warnings which show up on i386. mm/percpu.c:1873: warning: comparison of distinct pointer types lacks a cast mm/percpu.c:1879: warning: format '%lx' expects type 'long unsigned int', but argument 2 has type 'size_t' Signed-off-by:
Tejun Heo <tj@kernel.org> Reported-by:
Randy Dunlap <randy.dunlap@oracle.com>
-
- 03 Oct, 2009 11 commits
-
-
Christoph Lameter authored
RCU does not do dynamic allocations but it increments per cpu variables a lot. These instructions results in a move to a register and then back to memory. This patch will make it use the inc/dec instructions on x86 that do not need a register. Acked-by:
Paul E. McKenney <paulmck@linux.vnet.ibm.com> Signed-off-by:
Christoph Lameter <cl@linux-foundation.org> Signed-off-by:
-
Christoph Lameter authored
Using per cpu atomics for the vm statistics reduces their overhead. And in the case of x86 we are guaranteed that they will never race even in the lax form used for vm statistics. Acked-by:
-
Christoph Lameter authored
Just a slight optimization that removes one array lookup. The processor number is needed for other things as well so the get/put_cpu cannot be removed. Acked-by:
-
Christoph Lameter authored
The xfs_icsb_modify_counters() function no longer needs the cpu variable if we use this_cpu_ptr() and we can get rid of get/put_cpu(). Acked-by:
Christoph Hellwig <hch@lst.de> Acked-by:
Olaf Weber <olaf@sgi.com> Signed-off-by:
-
Christoph Lameter authored
There are cases where we can use this_cpu_ptr and as the result of using this_cpu_ptr() we no longer need to determine the currently executing cpu. In those places no get/put_cpu combination is needed anymore. The local cpu variable can be eliminated. Preemption still needs to be disabled and enabled since the modifications of the per cpu variables is not atomic. There may be multiple per cpu variables modified and those must all be from the same processor. Acked-by:
Maciej Sosnowski <maciej.sosnowski@intel.com> Acked-by:
Dan Williams <dan.j.williams@intel.com> Acked-by:
-
Christoph Lameter authored
Use this_cpu_ptr and __this_cpu_ptr in locations where straight transformations are possible because per_cpu_ptr is used with either smp_processor_id() or raw_smp_processor_id(). cc: David Howells <dhowells@redhat.com> Acked-by:
-
Christoph Lameter authored
Acked-by:
David Miller <davem@davemloft.net> Signed-off-by:
-
Christoph Lameter authored
Simplify NFS statistics and allow the use of optimized arch instructions. Acked-by:
-
Christoph Lameter authored
SNMP statistic macros can be signficantly simplified. This will also reduce code size if the arch supports these operations in hardware. Acked-by:
-
Christoph Lameter authored
Basically the existing percpu ops can be used for this_cpu variants that allow operations also on dynamically allocated percpu data. However, we do not pass a reference to a percpu variable in. Instead a dynamically or statically allocated percpu variable is provided. Preempt, the non preempt and the irqsafe operations generate the same code. It will always be possible to have the requires per cpu atomicness in a single RMW instruction with segment override on x86. 64 bit this_cpu operations are not supported on 32 bit. Signed-off-by:
-
Christoph Lameter authored
This patch introduces two things: First this_cpu_ptr and then per cpu atomic operations. this_cpu_ptr ------------ A common operation when dealing with cpu data is to get the instance of the cpu data associated with the currently executing processor. This can be optimized by this_cpu_ptr(xx) = per_cpu_ptr(xx, smp_processor_id). The problem with per_cpu_ptr(x, smp_processor_id) is that it requires an array lookup to find the offset for the cpu. Processors typically have the offset for the current cpu area in some kind of (arch dependent) efficiently accessible register or memory location. We can use that instead of doing the array lookup to speed up the determination of the address of the percpu variable. This is particularly significant because these lookups occur in performance critical paths of the core kernel. this_cpu_ptr() can avoid memory accesses and this_cpu_ptr comes in two flavors. The preemption context matters since we are referring the the currently executing processor. In many cases we must insure that the processor does not change while a code segment is executed. __this_cpu_ptr -> Do not check for preemption context this_cpu_ptr -> Check preemption context The parameter to these operations is a per cpu pointer. This can be the address of a statically defined per cpu variable (&per_cpu_var(xxx)) or the address of a per cpu variable allocated with the per cpu allocator. per cpu atomic operations: this_cpu_*(var, val) ----------------------------------------------- this_cpu_* operations (like this_cpu_add(struct->y, value) operate on abitrary scalars that are members of structures allocated with the new per cpu allocator. They can also operate on static per_cpu variables if they are passed to per_cpu_var() (See patch to use this_cpu_* operations for vm statistics). These operations are guaranteed to be atomic vs preemption when modifying the scalar. The calculation of the per cpu offset is also guaranteed to be atomic at the same time. This means that a this_cpu_* operation can be safely used to modify a per cpu variable in a context where interrupts are enabled and preemption is allowed. Many architectures can perform such a per cpu atomic operation with a single instruction. Note that the atomicity here is different from regular atomic operations. Atomicity is only guaranteed for data accessed from the currently executing processor. Modifications from other processors are still possible. There must be other guarantees that the per cpu data is not modified from another processor when using these instruction. The per cpu atomicity is created by the fact that the processor either executes and instruction or not. Embedded in the instruction is the relocation of the per cpu address to the are reserved for the current processor and the RMW action. Therefore interrupts or preemption cannot occur in the mids of this processing. Generic fallback functions are used if an arch does not define optimized this_cpu operations. The functions come also come in the two flavors used for this_cpu_ptr(). The firstparameter is a scalar that is a member of a structure allocated through allocpercpu or a per cpu variable (use per_cpu_var(xxx)). The operations are similar to what percpu_add() and friends do. this_cpu_read(scalar) this_cpu_write(scalar, value) this_cpu_add(scale, value) this_cpu_sub(scalar, value) this_cpu_inc(scalar) this_cpu_dec(scalar) this_cpu_and(scalar, value) this_cpu_or(scalar, value) this_cpu_xor(scalar, value) Arch code can override the generic functions and provide optimized atomic per cpu operations. These atomic operations must provide both the relocation (x86 does it through a segment override) and the operation on the data in a single instruction. Otherwise preempt needs to be disabled and there is no gain from providing arch implementations. A third variant is provided prefixed by irqsafe_. These variants are safe against hardware interrupts on the *same* processor (all per cpu atomic primitives are *always* *only* providing safety for code running on the *same* processor!). The increment needs to be implemented by the hardware in such a way that it is a single RMW instruction that is either processed before or after an interrupt. cc: David Howells <dhowells@redhat.com> cc: Ingo Molnar <mingo@elte.hu> cc: Rusty Russell <rusty@rustcorp.com.au> cc: Eric Dumazet <dada1@cosmosbay.com> Signed-off-by:
-
- 02 Oct, 2009 6 commits
-
-
Tejun Heo authored
With ia64 converted, there's no arch left which still uses legacy percpu allocator. Kill it. Signed-off-by:
Rusty Russell <rusty@rustcorp.com.au> Cc: Ingo Molnar <mingo@redhat.com> Cc: Christoph Lameter <cl@linux-foundation.org>
-
Tejun Heo authored
Unlike other archs, ia64 reserves space for percpu areas during early memory initialization. These areas occupy a contiguous region indexed by cpu number on contiguous memory model or are grouped by node on discontiguous memory model. As allocation and initialization are done by the arch code, all that setup_per_cpu_areas() needs to do is communicating the determined layout to the percpu allocator. This patch implements setup_per_cpu_areas() for both contig and discontig memory models and drops HAVE_LEGACY_PER_CPU_AREA. Please note that for contig model, the allocation itself is modified only to allocate for possible cpus instead of NR_CPUS. As dynamic percpu allocator can handle non-direct mapping, there's no reason to allocate memory for cpus which aren't possible. Signed-off-by:
Tony Luck <tony.luck@intel.com> Cc: Fenghua Yu <fenghua.yu@intel.com> Cc: linux-ia64 <linux-ia64@vger.kernel.org>
-
Tejun Heo authored
cpu0 used special percpu area reserved by the linker, __cpu0_per_cpu, which is set up early in boot by head.S. However, this doesn't guarantee that the area will be on the same node as cpu0 and the percpu area for cpu0 ends up very far away from percpu areas for other cpus which cause problems for congruent percpu allocator. This patch makes percpu area initialization allocate percpu area for cpu0 like any other cpus and copy it from __cpu0_per_cpu which now resides in the __init area. This means that for cpu0, percpu area is first setup at __cpu0_per_cpu early by head.S and then moved to an area in the linear mapping during memory initialization and it's not allowed to take a pointer to percpu variables between head.S and memory initialization. Signed-off-by:
-
Tejun Heo authored
All information necessary to initialize cpu possible and present maps are available once early_acpi_boot_init() is complete. Reorganize setup_arch() and acpi init functions such that, * CPU information is printed after LAPIC entries are parsed in early_acpi_boot_init(). * smp_build_cpu_map() is called by setup_arch() instead of acpi functions. * smp_build_cpu_map() is called once all CPU related information is available before memory is initialized. This is primarily to allow find_memory() to use cpu maps but is also a general cleanup. Please note that with this change, the somewhat ad-hoc early_cpu_possible_map defined and used for NUMA configurations is probably unnecessary. Something to clean up another day. Signed-off-by:
-
Tejun Heo authored
If CONFIG_VIRTUAL_MEM_MAP is enabled, ia64 defines macro VMALLOC_END as unsigned long variable vmalloc_end which is adjusted to prepare room for vmemmap. This becomes probnlematic if a local variables vmalloc_end is defined in some function (not very unlikely) and VMALLOC_END is used in the function - the function thinks its referencing the global VMALLOC_END value but would be referencing its own local vmalloc_end variable. There's no reason VMALLOC_END should be a macro. Just define it as an unsigned long variable if CONFIG_VIRTUAL_MEM_MAP is set to avoid nasty surprises. Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-unstableLinus Torvalds authored
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-unstable: Btrfs: fix data space leak fix Btrfs: remove duplicates of filemap_ helpers Btrfs: take i_mutex before generic_write_checks Btrfs: fix arguments to btrfs_wait_on_page_writeback_range Btrfs: fix deadlock with free space handling and user transactions Btrfs: fix error cases for ioctl transactions Btrfs: Use CONFIG_BTRFS_POSIX_ACL to enable ACL code Btrfs: introduce missing kfree Btrfs: Fix setting umask when POSIX ACLs are not enabled Btrfs: proper -ENOSPC handling
-
- 01 Oct, 2009 21 commits
-
-
Uwe Kleine-König authored
spi_imx_chipselect() made things that should be (and mostly are) done by spi_imx_setupxfer. Only setting the tx and rx functions was missing. Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by:
Sascha Hauer <s.hauer@pengutronix.de> Cc: David Brownell <dbrownell@users.sourceforge.net> Cc: Guennadi Liakhovetski <g.liakhovetski@gmx.de> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Uwe Kleine-König authored
Otherwise the config function uses random data from the stack. This didn't stick out because config is called once more in the chipselect function with correct parameters. Signed-off-by:
-
Uwe Kleine-König authored
spi_imx_setup() is only called by spi_setup(). The latter does the initialization already. Signed-off-by:
-
Sascha Hauer authored
Signed-off-by:
-
Sascha Hauer authored
We can only setup the gpio pins in spi_setup time when we know the SPI_CS_HIGH setting. Signed-off-by:
-
Sascha Hauer authored
Signed-off-by:
-
Uwe Kleine-König authored
This makes the filename match the Kconfig symbol and the driver name. Signed-off-by:
-
Christoph Hellwig authored
It's just a wrapper for <linux/fscache.h>, so remove it. Signed-off-by:
David Howells <dhowells@redhat.com> Signed-off-by:
-
Andy Spencer authored
When using %*s, sscanf should honor conversion specifiers immediately following the %*s. For example, the following code should find the position of the end of the string "hello". int end; char buf[] = "hello world"; sscanf(buf, "%*s%n", &end); printf("%d\n", end); Ideally, sscanf would advance the fmt and str pointers the same as it would without the *, but the code for that is rather complicated and is not included in the patch. Signed-off-by:Andy Spencer <andy753421@gmail.com> Acked-by:
WANG Cong <xiyou.wangcong@gmail.com> Signed-off-by:
-
Chuck Ebbert authored
Allow users to force skipping the TXEN test at init time. Applies to all serial ports. Intended for debugging only. There is a blacklist for devices where we need to skip the test but the list is not complete. This lets users force skipping the test so we can determine if they need to be added to the list. Some HP machines with weird serial consoles have this problem and there may be more. Signed-off-by:
Chuck Ebbert <cebbert@redhat.com> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Signed-off-by:
-
Roel Kluin authored
Check whether index is within bounds before grabbing the element. Also, since NR_PORTS is defined ARRAY_SIZE(cy_port), cy_port[NR_PORTS] is out of bounds as well. [akpm@linux-foundation.org: cleanup, remove (long) casts] Signed-off-by:
Roel Kluin <roel.kluin@gmail.com> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Cc: Jiri Slaby <jirislaby@gmail.com> Signed-off-by:
-
Roel Kluin authored
irq is declared with size NR_CARDS (4), but the loop containing this segment runs up until NR_ISA_ADDRS (16), possibly reading from irq[i] (and trying to use the result) Identified by the Parfait static scanner. Signed-off-by:
Jiri Slaby <jirislaby@gmail.com> Signed-off-by:
-
Breno Leitao authored
Convert spaces to tabs and remove wrong spaces Signed-off-by:
Breno Leitao <leitao@linux.vnet.ibm.com> Cc: Scott Kilau <Scott.Kilau@digi.com> Cc: Jiri Slaby <jirislaby@gmail.com> Signed-off-by:
-
Atsushi Nemoto authored
Signed-off-by:
Atsushi Nemoto <anemo@mba.ocn.ne.jp> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Signed-off-by:
-
Ben Dooks authored
Add better support for omitting either the card detect or the write protect GPIOs if the board does not support it. Add the fields no_wprotect and no_detect to the platform data which when set indicate the absence of the respective GPIOs. Note, this also fixes a minor bug where it tries to free IRQ0 if there is no detect gpio available. Signed-off-by:
Ben Dooks <ben@simtec.co.uk> Cc: <linux-mmc@vger.kernel.org> Signed-off-by:
-
Ben Dooks authored
We have found a couple of boards where the SDIO IRQ hardware support has failed to work properly, and thus we should make it configurable whether or not to be included in the driver. Signed-off-by:
-
Ben Dooks authored
Fixes for the DMA transfer mode of the driver to try and improve the state of the code: - Ensure that dma_complete is set during the end of the command phase so that transfers do not stall awaiting the completion - Update the DMA debugging to provide a bit more useful information such as how many DMA descriptors where not processed and print the DMA addresses in hexadecimal. - Fix the DMA channel request code to actually request DMA for the S3CMCI block instead of whatever '0' signified. - Add fallback to PIO if we cannot get the DMA channel, as many of the devices with this block only have a limited number of DMA channels. - Only try and claim and free the DMA channel if we are trying to use it. This improves the driver DMA code to the point where it can now identify a card and read the partition table. However the DMA can still stall when trying to move data between the host and memory. Signed-off-by:
-
Ben Dooks authored
Add a selection for the data transfer mode of the s3cmci driver, allowing for either a configuration or rumtime selection of the use of the DMA or PIO transfer code. The PIO only mode is 476 bytes smaller than the driver with both methods compiled in. Signed-off-by:
-
Ben Dooks authored
The controller supports SDIO IRQ detection so add support for hardware assisted SDIO interrupt detection for the SDIO core. This improves the response time for SDIO interrupts and thus the transfer rate from devices such as the Marvel 8686. As a note, it does seem that the controller will miss an IRQ than is held asserted, so there are some manual checks to see if the SDIO interrupt is active after a transfer. Major testing on the S3C2440. Signed-off-by:
-
Ben Dooks authored
Export driver state and hardware register state via debugfs entries created under a directory formed from dev_name() on the probed device when CONFIG_DEBUG_FS is set. Signed-off-by:
-
Ben Dooks authored
The clear_imask() call should be used to clear the interrupt mask register, as it may end up clearing the SDIO interrupt bit if this is enabled. Change all writes of zero to SDIIMSK register to use clear_imask() ready for the SDIO updates. Signed-off-by:
-
