- 27 Apr, 2013 1 commit
-
-
Paul E. McKenney authored
The Linux kernel uses a number of per-CPU kthreads, any of which might contribute to OS jitter at any time. The usual approach to normal kthreads, namely to bind them to a "housekeeping" CPU, does not work with these kthreads because they cannot operate correctly if moved to some other CPU. This commit therefore lists ways of controlling OS jitter from the Linux kernel's per-CPU kthreads. It also lists some ways of diagnosing excessive jitter. Signed-off-by:
Paul E. McKenney <paulmck@linux.vnet.ibm.com> Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: Steven Rostedt <rostedt@goodmis.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Arjan van de Ven <arjan@linux.intel.com> Cc: Kevin Hilman <khilman@linaro.org> Cc: Christoph Lameter <cl@linux.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Olivier Baetz <olivier.baetz@novasparks.com> Cc: Pradeep Satyanarayana <pradeeps@linux.vnet.ibm.com> Reviewed-by:
Randy Dunlap <rdunlap@infradead.org> Reviewed-by:
Borislav Petkov <bp@suse.de>
-
- 26 Mar, 2013 15 commits
-
-
Paul E. McKenney authored
doc.2013.03.12a: Documentation changes. fixes.2013.03.13a: Miscellaneous fixes. idlenocb.2013.03.26b: Remove restrictions on no-CBs CPUs, make RCU_FAST_NO_HZ take advantage of numbered callbacks, add callback acceleration based on numbered callbacks.
-
Paul E. McKenney authored
Now that rcu_start_future_gp() has been abstracted from rcu_nocb_wait_gp(), rcu_accelerate_cbs() can invoke rcu_start_future_gp() so as to register the need for any future grace periods needed by a CPU about to enter dyntick-idle mode. This commit makes this change. Note that some refactoring of rcu_start_gp() is carried out to avoid recursion and subsequent self-deadlocks. Signed-off-by:
Paul E. McKenney <paul.mckenney@linaro.org> Signed-off-by:
-
Paul E. McKenney authored
CPUs going idle will need to record the need for a future grace period, but won't actually need to block waiting on it. This commit therefore splits rcu_start_future_gp(), which does the recording, from rcu_nocb_wait_gp(), which now invokes rcu_start_future_gp() to do the recording, after which rcu_nocb_wait_gp() does the waiting. Signed-off-by:
-
Paul E. McKenney authored
CPUs going idle need to be able to indicate their need for future grace periods. A mechanism for doing this already exists for no-callbacks CPUs, so the idea is to re-use that mechanism. This commit therefore moves the ->n_nocb_gp_requests field of the rcu_node structure out from under the CONFIG_RCU_NOCB_CPU #ifdef and renames it to ->need_future_gp. Signed-off-by:
-
Paul E. McKenney authored
If CPUs are to give prior notice of needed grace periods, it will be necessary to invoke rcu_start_gp() without dropping the root rcu_node structure's ->lock. This commit takes a second step in this direction by moving the release of this lock to rcu_start_gp()'s callers. Signed-off-by:
-
Paul E. McKenney authored
Dyntick-idle CPUs need to be able to pre-announce their need for grace periods. This can be done using something similar to the mechanism used by no-CB CPUs to announce their need for grace periods. This commit moves in this direction by renaming the no-CBs grace-period event tracing to suit the new future-grace-period needs. Signed-off-by:
-
Paul E. McKenney authored
If CPUs are to give prior notice of needed grace periods, it will be necessary to invoke rcu_start_gp() without dropping the root rcu_node structure's ->lock. This commit takes a first step in this direction by moving the release of this lock to the end of rcu_start_gp(). Signed-off-by:
-
Paul E. McKenney authored
Because RCU callbacks are now associated with the number of the grace period that they must wait for, CPUs can now take advance callbacks corresponding to grace periods that ended while a given CPU was in dyntick-idle mode. This eliminates the need to try forcing the RCU state machine while entering idle, thus reducing the CPU intensiveness of RCU_FAST_NO_HZ, which should increase its energy efficiency. Signed-off-by:
-
Paul E. McKenney authored
Now that callback acceleration is idempotent, it is safe to accelerate callbacks during grace-period cleanup on any CPUs that the kthread happens to be running on. This commit therefore propagates the completion of the grace period to the per-CPU data structures, and also adds an rcu_advance_cbs() just before the cpu_needs_another_gp() check in order to reduce false-positive grace periods. Signed-off-by: -
Paul E. McKenney authored
RCU_FAST_NO_HZ operation is controlled by four compile-time C-preprocessor macros, but some use cases benefit greatly from runtime adjustment, particularly when tuning devices. This commit therefore creates the corresponding sysfs entries. Reported-by:
Robin Randhawa <robin.randhawa@arm.com> Signed-off-by:
-
Paul E. McKenney authored
Currently, the per-no-CBs-CPU kthreads are named "rcuo" followed by the CPU number, for example, "rcuo". This is problematic given that there are either two or three RCU flavors, each of which gets a per-CPU kthread with exactly the same name. This commit therefore introduces a one-letter abbreviation for each RCU flavor, namely 'b' for RCU-bh, 'p' for RCU-preempt, and 's' for RCU-sched. This abbreviation is used to distinguish the "rcuo" kthreads, for example, for CPU 0 we would have "rcuob/0", "rcuop/0", and "rcuos/0". Signed-off-by:
Dietmar Eggemann <dietmar.eggemann@arm.com>
-
Paul E. McKenney authored
Signed-off-by:
-
Paul E. McKenney authored
Signed-off-by:
-
Paul E. McKenney authored
Currently, the no-CBs kthreads do repeated timed waits for grace periods to elapse. This is crude and energy inefficient, so this commit allows no-CBs kthreads to specify exactly which grace period they are waiting for and also allows them to block for the entire duration until the desired grace period completes. Signed-off-by:
-
Paul E. McKenney authored
Currently, the only way to specify no-CBs CPUs is via the rcu_nocbs kernel command-line parameter. This is inconvenient in some cases, particularly for randconfig testing, so this commit adds a new set of kernel configuration parameters. CONFIG_RCU_NOCB_CPU_NONE (the default) retains the old behavior, CONFIG_RCU_NOCB_CPU_ZERO offloads callback processing from CPU 0 (along with any other CPUs specified by the rcu_nocbs boot-time parameter), and CONFIG_RCU_NOCB_CPU_ALL offloads callback processing from all CPUs. Signed-off-by:
-
- 13 Mar, 2013 2 commits
-
-
Paul E. McKenney authored
In some situations, randomly delaying RCU grace-period initialization can cause more trouble than help. This commit therefore restricts this type of RCU self-torture to runtime, giving it a rest during boot and shutdown. Reported-by:
Sasha Levin <sasha.levin@oracle.com> Signed-off-by:
-
Paul E. McKenney authored
If RCU's softirq handler is prevented from executing, an RCU CPU stall warning can result. Ways to prevent RCU's softirq handler from executing include: (1) CPU spinning with interrupts disabled, (2) infinite loop in some softirq handler, and (3) in -rt kernels, an infinite loop in a set of real-time threads running at priorities higher than that of RCU's softirq handler. Because this situation can be difficult to track down, this commit causes the count of RCU softirq handler invocations to be printed with RCU CPU stall warnings. This information does require some interpretation, as now documented in Documentation/RCU/stallwarn.txt. Reported-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
Paul Gortmaker <paul.gortmaker@windriver.com>
-
- 12 Mar, 2013 8 commits
-
-
Paul E. McKenney authored
This commit applies a few updates based on a quick review of the RCU documentations. Signed-off-by: -
Paul E. McKenney authored
One of the code samples in whatisRCU.txt shows a bug, but someone scanning the document quickly might mistake it for a valid use of RCU. Add some screaming comments to help keep speed-readers on track. Reported-by:
Nathan Zimmer <nzimmer@sgi.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
Steven Whitehouse authored
Abhi noticed that we were getting a complaint from the RCU subsystem about access of an RCU protected list under the write side bit lock. This commit adds additional annotation to check both the RCU read lock and the write side bit lock before printing a message. Reported by: Abhijith Das <adas@redhat.com> Signed-off-by:
Steven Whitehouse <swhiteho@redhat.com> Tested-by:
Abhijith Das <adas@redhat.com> Signed-off-by:
-
Paul E. McKenney authored
Signed-off-by: -
Srivatsa S. Bhat authored
Although it used to be that CPU_DYING notifiers executed on the outgoing CPU with interrupts disabled and with all other CPUs spinning, this is no longer the case. This commit therefore removes this obsolete comment. Signed-off-by:
Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> Signed-off-by:
-
Paul E. McKenney authored
Offline CPUs transition through the scheduler to the idle loop one last time before being shut down. This can result in RCU raising softirq on this CPU, which is at best useless given that the CPU's callbacks will be offloaded at CPU_DEAD time. This commit therefore avoids raising softirq on offline CPUs. Signed-off-by: -
Jiang Fang authored
Signed-off-by:
Jiang Fang <jiang.xx.fang@gmail.com> Signed-off-by:
-
Paul E. McKenney authored
Currently, CPU 0 is constrained to not be a no-CBs CPU, and furthermore at least one no-CBs CPU must remain online at any given time. These restrictions are problematic in some situations, such as cases where all CPUs must run a real-time workload that needs to be insulated from OS jitter and latencies due to RCU callback invocation. This commit therefore provides no-CBs CPUs a (very crude and energy-inefficient) way to start and to wait for grace periods independently of the normal RCU callback mechanisms. This approach allows any or all of the CPUs to be designated as no-CBs CPUs, and allows any proper subset of the CPUs (whether no-CBs CPUs or not) to be offlined. This commit also provides a fix for a locking bug spotted by Xie ChanglongX <changlongx.xie@intel.com>. Signed-off-by:
-
- 10 Mar, 2013 2 commits
-
-
Linus Torvalds authored
-
git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespaceLinus Torvalds authored
Pull namespace bugfixes from Eric Biederman: "This is three simple fixes against 3.9-rc1. I have tested each of these fixes and verified they work correctly. The userns oops in key_change_session_keyring and the BUG_ON triggered by proc_ns_follow_link were found by Dave Jones. I am including the enhancement for mount to only trigger requests of filesystem modules here instead of delaying this for the 3.10 merge window because it is both trivial and the kind of change that tends to bit-rot if left untouched for two months." * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace: proc: Use nd_jump_link in proc_ns_follow_link fs: Limit sys_mount to only request filesystem modules (Part 2). fs: Limit sys_mount to only request filesystem modules. userns: Stop oopsing in key_change_session_keyring
-
- 09 Mar, 2013 5 commits
-
-
Linus Torvalds authored
There is a more complete atmel patch-series out by Nick Dyer that fixes this and other things, but in the meantime this is the minimal thing to get the touchscreen going on (at least my) Pixel Chromebook. Not that I want my dirty fingers near that beautiful screen, but it seems that a non-initialized touchscreen will also end up being a constant wakeup source, so you have to disable it to go to sleep. And it's easier to just fix the initialization sequence. Signed-off-by:Linus Torvalds <torvalds@linux-foundation.org>
-
Eric W. Biederman authored
Update proc_ns_follow_link to use nd_jump_link instead of just manually updating nd.path.dentry. This fixes the BUG_ON(nd->inode != parent->d_inode) reported by Dave Jones and reproduced trivially with mkdir /proc/self/ns/uts/a. Sigh it looks like the VFS change to require use of nd_jump_link happend while proc_ns_follow_link was baking and since the common case of proc_ns_follow_link continued to work without problems the need for making this change was overlooked. Cc: stable@vger.kernel.org Signed-off-by:"Eric W. Biederman" <ebiederm@xmission.com>
-
git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfsLinus Torvalds authored
Pull btrfs fixes from Chris Mason: "These are scattered fixes and one performance improvement. The biggest functional change is in how we throttle metadata changes. The new code bumps our average file creation rate up by ~13% in fs_mark, and lowers CPU usage. Stefan bisected out a regression in our allocation code that made balance loop on extents larger than 256MB." * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs: Btrfs: improve the delayed inode throttling Btrfs: fix a mismerge in btrfs_balance() Btrfs: enforce min_bytes parameter during extent allocation Btrfs: allow running defrag in parallel to administrative tasks Btrfs: avoid deadlock on transaction waiting list Btrfs: do not BUG_ON on aborted situation Btrfs: do not BUG_ON in prepare_to_reloc Btrfs: free all recorded tree blocks on error Btrfs: build up error handling for merge_reloc_roots Btrfs: check for NULL pointer in updating reloc roots Btrfs: fix unclosed transaction handler when the async transaction commitment fails Btrfs: fix wrong handle at error path of create_snapshot() when the commit fails Btrfs: use set_nlink if our i_nlink is 0
-
Benson Leung authored
Add basic platform data to get the current upstream driver working with the 224s touchpad and 1664s touchscreen. We will be using NULL config so we will use the settings from the devices' NVRAMs. Signed-off-by:
Benson Leung <bleung@chromium.org> Tested-by:
Olof Johansson <olof@lixom.net> Signed-off-by:
-
Daniel Kurtz authored
This same driver can be used by atmel based touchscreens and touchpads (buttonpads). Platform data may specify a device is a touchpad using the is_tp flag. This will cause the driver to perform some touchpad specific initializations, such as: * register input device name "Atmel maXTouch Touchpad" instead of Touchscreen. * register BTN_LEFT & BTN_TOOL_* event types. * register axis resolution (as a fixed constant, for now) * register BUTTONPAD property * process GPIO buttons using reportid T19 Input event GPIO mapping is done by the platform data key_map array. key_map[x] should contain the KEY or BTN code to send when processing GPIOx from T19. To specify a GPIO as not an input source, populate with KEY_RESERVED, or 0. Signed-off-by:
Daniel Kurtz <djkurtz@chromium.org> Signed-off-by:
Nick Dyer <nick.dyer@itdev.co.uk> Tested-by:
-
- 08 Mar, 2013 7 commits
-
-
git://git.samba.org/sfrench/cifs-2.6Linus Torvalds authored
Pull CIFS fixes from Steve French: "A small set of cifs fixes which includes one for a recent regression in the write path (pointed out by Anton), some fixes for rename problems and as promised for 3.9 removing the obsolete sockopt mount option (and the accompanying deprecation warning)." * 'for-next' of git://git.samba.org/sfrench/cifs-2.6: CIFS: Fix missing of oplock_read value in smb30_values structure cifs: don't try to unlock pagecache page after releasing it cifs: remove the sockopt= mount option cifs: Check server capability before attempting silly rename cifs: Fix bug when checking error condition in cifs_rename_pending_delete()
-
Linus Torvalds authored
Merge misc fixes from Andrew Morton. * emailed patches from Andrew Morton <akpm@linux-foundation.org>: alpha: boot: fix build breakage introduced by system.h disintegration memcg: initialize kmem-cache destroying work earlier Randy has moved ksm: fix m68k build: only NUMA needs pfn_to_nid dmi_scan: fix missing check for _DMI_ signature in smbios_present() Revert parts of "hlist: drop the node parameter from iterators" idr: remove WARN_ON_ONCE() on negative IDs mm/mempolicy.c: fix sp_node_init() argument ordering mm/mempolicy.c: fix wrong sp_node insertion ipc: don't allocate a copy larger than max ipc: fix potential oops when src msg > 4k w/ MSG_COPY
-
Will Deacon authored
Commit ec221208 ("Disintegrate asm/system.h for Alpha") removed the system.h include from boot/head.S, which puts the PAL_* asm constants out of scope. Include <asm/pal.h> so we can get building again. Signed-off-by:
Will Deacon <will.deacon@arm.com> Cc: David Rusling <david.rusling@linaro.org> Cc: David Howells <dhowells@redhat.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Konstantin Khlebnikov authored
Fix a warning from lockdep caused by calling cancel_work_sync() for uninitialized struct work. This path has been triggered by destructon kmem-cache hierarchy via destroying its root kmem-cache. cache ffff88003c072d80 obj ffff88003b410000 cache ffff88003c072d80 obj ffff88003b924000 cache ffff88003c20bd40 INFO: trying to register non-static key. the code is fine but needs lockdep annotation. turning off the locking correctness validator. Pid: 2825, comm: insmod Tainted: G O 3.9.0-rc1-next-20130307+ #611 Call Trace: __lock_acquire+0x16a2/0x1cb0 lock_acquire+0x8a/0x120 flush_work+0x38/0x2a0 __cancel_work_timer+0x89/0xf0 cancel_work_sync+0xb/0x10 kmem_cache_destroy_memcg_children+0x81/0xb0 kmem_cache_destroy+0xf/0xe0 init_module+0xcb/0x1000 [kmem_test] do_one_initcall+0x11a/0x170 load_module+0x19b0/0x2320 SyS_init_module+0xc6/0xf0 system_call_fastpath+0x16/0x1b Example module to demonstrate: #include <linux/module.h> #include <linux/slab.h> #include <linux/mm.h> #include <linux/workqueue.h> int __init mod_init(void) { int size = 256; struct kmem_cache *cache; void *obj; struct page *page; cache = kmem_cache_create("kmem_cache_test", size, size, 0, NULL); if (!cache) return -ENOMEM; printk("cache %p\n", cache); obj = kmem_cache_alloc(cache, GFP_KERNEL); if (obj) { page = virt_to_head_page(obj); printk("obj %p cache %p\n", obj, page->slab_cache); kmem_cache_free(cache, obj); } flush_scheduled_work(); obj = kmem_cache_alloc(cache, GFP_KERNEL); if (obj) { page = virt_to_head_page(obj); printk("obj %p cache %p\n", obj, page->slab_cache); kmem_cache_free(cache, obj); } kmem_cache_destroy(cache); return -EBUSY; } module_init(mod_init); MODULE_LICENSE("GPL"); Signed-off-by:Konstantin Khlebnikov <khlebnikov@openvz.org> Cc: Glauber Costa <glommer@parallels.com> Signed-off-by:
-
Randy Dunlap authored
Update email address and CREDITS info. xenotime.net is defunct. Signed-off-by:
-
Hugh Dickins authored
A CONFIG_DISCONTIGMEM=y m68k config gave mm/ksm.c: In function `get_kpfn_nid': mm/ksm.c:492: error: implicit declaration of function `pfn_to_nid' linux/mmzone.h declares it for CONFIG_SPARSEMEM and CONFIG_FLATMEM, but expects the arch's asm/mmzone.h to declare it for CONFIG_DISCONTIGMEM (see arch/mips/include/asm/mmzone.h for example). Or perhaps it is only expected when CONFIG_NUMA=y: too much of a maze, and m68k got away without it so far, so fix the build in mm/ksm.c. Signed-off-by:
Hugh Dickins <hughd@google.com> Reported-by:
Geert Uytterhoeven <geert@linux-m68k.org> Cc: Petr Holasek <pholasek@redhat.com> Signed-off-by:
-
Ben Hutchings authored
Commit 9f9c9cbb ("drivers/firmware/dmi_scan.c: fetch dmi version from SMBIOS if it exists") hoisted the check for "_DMI_" into dmi_scan_machine(), which means that we don't bother to check for "_DMI_" at offset 16 in an SMBIOS entry. smbios_present() may also call dmi_present() for an address where we found "_SM_", if it failed further validation. Check for "_DMI_" in smbios_present() before calling dmi_present(). [akpm@linux-foundation.org: fix build] Signed-off-by:
Ben Hutchings <ben@decadent.org.uk> Reported-by:
Tim McGrath <tmhikaru@gmail.com> Tested-by:
-
