- 01 Apr, 2010 34 commits
-
-
Bruce Allan authored
commit 9e135a2e upstream. This new PCI device ID is for a new combination of MAC and PHY both of which already have supporting code in the driver, just not yet in this combination. During validation of the device, an intermittent issue was discovered with waking it from a suspended state which can be resolved with the pre-existing workaround to disable gigabit speed prior to suspending. Signed-off-by:
Bruce Allan <bruce.w.allan@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Kees Cook authored
commit 0e1a6ef2 upstream. Currently the mmap_min_addr value can only be bypassed during mmap when the task has CAP_SYS_RAWIO. However, the mmap_min_addr sysctl value itself can be adjusted to 0 if euid == 0, allowing a bypass without CAP_SYS_RAWIO. This patch adds a check for the capability before allowing mmap_min_addr to be changed. Signed-off-by:
Kees Cook <kees.cook@canonical.com> Acked-by:
Serge Hallyn <serue@us.ibm.com> Signed-off-by:
James Morris <jmorris@namei.org> Signed-off-by:
-
David S. Miller authored
[ Upstream commit 8a4fd1e4 ] If we do something like try to print to the OF console from an NMI while we're already in OpenFirmware, we'll deadlock on the spinlock. Use a raw spinlock and disable NMIs when we take it. Signed-off-by:
-
Peter Zijlstra authored
commit 933b0618 upstream. A UP machine has 1 active cpu, not having the boot-cpu in the active map when starting the scheduler confuses things. Signed-off-by:
Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Mike Galbraith <efault@gmx.de> LKML-Reference: <20091216170517.423469527@chello.nl> Signed-off-by:
Ingo Molnar <mingo@elte.hu> Cc: Christoph Biedl <linux-kernel.bfrz@manchmal.in-ulm.de> Signed-off-by:
-
Alexander Duyck authored
commit 7a0deb6b upstream. This patch adds support for the 82576NS Serdes adapter to the existing pci quirk for 82576 parts. Signed-off-by:
Alexander Duyck <alexander.h.duyck@intel.com> Signed-off-by:
-
Srinivas authored
commit 7ec4ad01 upstream. This is support for Adaptec ASC-1045/1405 SAS/SATA HBA on mvsas, which is based on Marvell 88SE6440 chipset. Signed-off-by:
Srinivas <satyasrinivasp@hcl.in> Cc: Andy Yan <ayan@marvell.com> Signed-off-by:
James Bottomley <James.Bottomley@suse.de> Cc: Thomas Voegtle <tv@lio96.de> Signed-off-by:
-
Suresh Siddha authored
commit 681ee44d upstream We need to fall back from logical-flat APIC mode to physical-flat mode when we have more than 8 CPUs. However, in the presence of CPU hotplug(with bios listing not enabled but possible cpus as disabled cpus in MADT), we have to consider the number of possible CPUs rather than the number of current CPUs; otherwise we may cross the 8-CPU boundary when CPUs are added later. 32bit apic code can use more cleanups (like the removal of vendor checks in 32bit default_setup_apic_routing()) and more unifications with 64bit code. Yinghai has some patches in works already. This patch addresses the boot issue that is reported in the virtualization guest context. Signed-off-by:
Suresh Siddha <suresh.b.siddha@intel.com> Acked-by:
Shaohui Zheng <shaohui.zheng@intel.com> Reviewed-by:
Yinghai Lu <yinghai@kernel.org> Signed-off-by:
H. Peter Anvin <hpa@zytor.com> Signed-off-by:
-
Thomas Gleixner authored
commit 41d2e494 upstream. The hrtimer_interrupt hang logic adjusts min_delta_ns based on the execution time of the hrtimer callbacks. This is error-prone for virtual machines, where a guest vcpu can be scheduled out during the execution of the callbacks (and the callbacks themselves can do operations that translate to blocking operations in the hypervisor), which in can lead to large min_delta_ns rendering the system unusable. Replace the current heuristics with something more reliable. Allow the interrupt code to try 3 times to catch up with the lost time. If that fails use the total time spent in the interrupt handler to defer the next timer interrupt so the system can catch up with other things which got delayed. Limit that deferment to 100ms. The retry events and the maximum time spent in the interrupt handler are recorded and exposed via /proc/timer_list Inspired by a patch from Marcelo. Reported-by:
Michael Tokarev <mjt@tls.msk.ru> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Tested-by:
Marcelo Tosatti <mtosatti@redhat.com> Cc: kvm@vger.kernel.org Cc: Jeremy Fitzhardinge <jeremy@goop.org> Signed-off-by:
-
Francesco Lavra authored
commit 19f48cb1 upstream. this patch fixes a memory leak which occurs when an em28xx card with DVB extension is unplugged or its DVB extension driver is unloaded. In dvb_fini(), dev->dvb must be freed before being set to NULL, as is done in dvb_init() in case of error. Note that this bug is also present in the latest stable kernel release. Signed-off-by:
Francesco Lavra <francescolavra@interfree.it> Signed-off-by:
Mauro Carvalho Chehab <mchehab@redhat.com> Signed-off-by:
-
Neil Horman authored
commit 76595f79 upstream. Modify uid check in do_coredump so as to not apply it in the case of pipes. This just got noticed in testing. The end of do_coredump validates the uid of the inode for the created file against the uid of the crashing process to ensure that no one can pre-create a core file with different ownership and grab the information contained in the core when they shouldn' tbe able to. This causes failures when using pipes for a core dumps if the crashing process is not root, which is the uid of the pipe when it is created. The fix is simple. Since the check for matching uid's isn't relevant for pipes (a process can't create a pipe that the uermodehelper code will open anyway), we can just just skip it in the event ispipe is non-zero Reverts a pipe-affecting change which was accidentally made in : commit c46f739d : Author: Ingo Molnar <mingo@elte.hu> : AuthorDate: Wed Nov 28 13:59:18 2007 +0100 : Commit: Linus Torvalds <torvalds@woody.linux-foundation.org> : CommitDate: Wed Nov 28 10:58:01 2007 -0800 : : vfs: coredumping fix Signed-off-by:
Neil Horman <nhorman@tuxdriver.com> Cc: Andi Kleen <andi@firstfloor.org> Cc: Oleg Nesterov <oleg@redhat.com> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Ingo Molnar <mingo@elte.hu> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Cc: maximilian attems <max@stro.at> Signed-off-by:
-
Marcin Slusarz authored
commit 89f3f219 upstream. Commit 4410f391 ("fbdev: add support for handoff from firmware to hw framebuffers") didn't add fb_destroy operation to efifb. Fix it and change aperture_size to match size passed to request_mem_region. Addresses http://bugzilla.kernel.org/show_bug.cgi?id=15151Signed-off-by:
Marcin Slusarz <marcin.slusarz@gmail.com> Reported-by:
Alex Zhavnerchik <alex.vizor@gmail.com> Tested-by:
Peter Jones <pjones@redhat.com> Cc: Huang Ying <ying.huang@intel.com> Cc: Dave Airlie <airlied@redhat.com> Cc: "Rafael J. Wysocki" <rjw@sisk.pl> Signed-off-by:
-
Adam Jackson authored
commit 9cf00977 upstream. Also fix an embarassing bug in standard timing subblock parsing that would result in an infinite loop. Signed-off-by:
Adam Jackson <ajax@redhat.com> Signed-off-by:
Dave Airlie <airlied@redhat.com> Cc: maximilian attems <max@stro.at> Signed-off-by:
-
Andrew Patterson authored
commit 6cdfd995 upstream. The current implementation of pci_cleanup_aer_uncorrect_error_status only clears either fatal or non-fatal error status bits depending on the state of the I/O channel. This implementation will then often leave some bits set after PCI error recovery completes. The uncleared bit settings will then be falsely reported the next time an AER interrupt is generated for that hierarchy. An easy way to illustrate this issue is to use the aer-inject module to simultaneously inject both an uncorrectable non-fatal and uncorrectable fatal error. One of the errors will not be cleared. This patch resolves this issue by unconditionally clearing all bits in the AER uncorrectable status register. All settings and corrective action strategies are saved and determined before pci_cleanup_aer_uncorrect_error_status is called, so this change should not affect errory handling functionality. Signed-off-by:
Andrew Patterson <andrew.patterson@hp.com> Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Cc: Alex Chiang <achiang@hp.com> Signed-off-by:
-
Steven Rostedt authored
commit b6345879 upstream. A bug was found with Li Zefan's ftrace_stress_test that caused applications to segfault during the test. Placing a tracing_off() in the segfault code, and examining several traces, I found that the following was always the case. The lock tracer was enabled (lockdep being required) and userstack was enabled. Testing this out, I just enabled the two, but that was not good enough. I needed to run something else that could trigger it. Running a load like hackbench did not work, but executing a new program would. The following would trigger the segfault within seconds: # echo 1 > /debug/tracing/options/userstacktrace # echo 1 > /debug/tracing/events/lock/enable # while :; do ls > /dev/null ; done Enabling the function graph tracer and looking at what was happening I finally noticed that all cashes happened just after an NMI. 1) | copy_user_handle_tail() { 1) | bad_area_nosemaphore() { 1) | __bad_area_nosemaphore() { 1) | no_context() { 1) | fixup_exception() { 1) 0.319 us | search_exception_tables(); 1) 0.873 us | } [...] 1) 0.314 us | __rcu_read_unlock(); 1) 0.325 us | native_apic_mem_write(); 1) 0.943 us | } 1) 0.304 us | rcu_nmi_exit(); [...] 1) 0.479 us | find_vma(); 1) | bad_area() { 1) | __bad_area() { After capturing several traces of failures, all of them happened after an NMI. Curious about this, I added a trace_printk() to the NMI handler to read the regs->ip to see where the NMI happened. In which I found out it was here: ffffffff8135b660 <page_fault>: ffffffff8135b660: 48 83 ec 78 sub $0x78,%rsp ffffffff8135b664: e8 97 01 00 00 callq ffffffff8135b800 <error_entry> What was happening is that the NMI would happen at the place that a page fault occurred. It would call rcu_read_lock() which was traced by the lock events, and the user_stack_trace would run. This would trigger a page fault inside the NMI. I do not see where the CR2 register is saved or restored in NMI handling. This means that it would corrupt the page fault handling that the NMI interrupted. The reason the while loop of ls helped trigger the bug, was that each execution of ls would cause lots of pages to be faulted in, and increase the chances of the race happening. The simple solution is to not allow user stack traces in NMI context. After this patch, I ran the above "ls" test for a couple of hours without any issues. Without this patch, the bug would trigger in less than a minute. Reported-by:
Li Zefan <lizf@cn.fujitsu.com> Signed-off-by:
Steven Rostedt <rostedt@goodmis.org> Signed-off-by:
-
Steven Rostedt authored
commit a2f80714 upstream. When the trace iterator is read, tracing_start() and tracing_stop() is called to stop tracing while the iterator is processing the trace output. These functions disable both the standard buffer and the max latency buffer. But if the wakeup tracer is running, it can switch these buffers between the two disables: buffer = global_trace.buffer; if (buffer) ring_buffer_record_disable(buffer); <<<--------- swap happens here buffer = max_tr.buffer; if (buffer) ring_buffer_record_disable(buffer); What happens is that we disabled the same buffer twice. On tracing_start() we can enable the same buffer twice. All ring_buffer_record_disable() must be matched with a ring_buffer_record_enable() or the buffer can be disable permanently, or enable prematurely, and cause a bug where a reset happens while a trace is commiting. This patch protects these two by taking the ftrace_max_lock to prevent a switch from occurring. Found with Li Zefan's ftrace_stress_test. Reported-by:
Lai Jiangshan <laijs@cn.fujitsu.com> Signed-off-by:
-
Steven Rostedt authored
commit 283740c6 upstream. In the ftrace code that resets the ring buffer it references the buffer with a local variable, but then uses the tr->buffer as the parameter to reset. If the wakeup tracer is running, which can switch the tr->buffer with the max saved buffer, this can break the requirement of disabling the buffer before the reset. buffer = tr->buffer; ring_buffer_record_disable(buffer); synchronize_sched(); __tracing_reset(tr->buffer, cpu); If the tr->buffer is swapped, then the reset is not happening to the buffer that was disabled. This will cause the ring buffer to fail. Found with Li Zefan's ftrace_stress_test. Reported-by:
-
Marcel Holtmann authored
commit 485f1eff upstream. With the commit 9e726b17 the rfcomm_session_put() gets accidentially called from a timeout callback and results in this: BUG: sleeping function called from invalid context at net/core/sock.c:1897 in_atomic(): 1, irqs_disabled(): 0, pid: 0, name: swapper Pid: 0, comm: swapper Tainted: P 2.6.32 #31 Call Trace: <IRQ> [<ffffffff81036455>] __might_sleep+0xf8/0xfa [<ffffffff8138ef1d>] lock_sock_nested+0x29/0xc4 [<ffffffffa03921b3>] lock_sock+0xb/0xd [l2cap] [<ffffffffa03948e6>] l2cap_sock_shutdown+0x1c/0x76 [l2cap] [<ffffffff8106adea>] ? clockevents_program_event+0x75/0x7e [<ffffffff8106bea2>] ? tick_dev_program_event+0x37/0xa5 [<ffffffffa0394967>] l2cap_sock_release+0x27/0x67 [l2cap] [<ffffffff8138c971>] sock_release+0x1a/0x67 [<ffffffffa03d2492>] rfcomm_session_del+0x34/0x53 [rfcomm] [<ffffffffa03d24c5>] rfcomm_session_put+0x14/0x16 [rfcomm] [<ffffffffa03d28b4>] rfcomm_session_timeout+0xe/0x1a [rfcomm] [<ffffffff810554a8>] run_timer_softirq+0x1e2/0x29a [<ffffffffa03d28a6>] ? rfcomm_session_timeout+0x0/0x1a [rfcomm] [<ffffffff8104e0f6>] __do_softirq+0xfe/0x1c5 [<ffffffff8100e8ce>] ? timer_interrupt+0x1a/0x21 [<ffffffff8100cc4c>] call_softirq+0x1c/0x28 [<ffffffff8100e05b>] do_softirq+0x33/0x6b [<ffffffff8104daf6>] irq_exit+0x36/0x85 [<ffffffff8100d7a9>] do_IRQ+0xa6/0xbd [<ffffffff8100c493>] ret_from_intr+0x0/0xa <EOI> [<ffffffff812585b3>] ? acpi_idle_enter_bm+0x269/0x294 [<ffffffff812585a9>] ? acpi_idle_enter_bm+0x25f/0x294 [<ffffffff81373ddc>] ? cpuidle_idle_call+0x97/0x107 [<ffffffff8100aca0>] ? cpu_idle+0x53/0xaa [<ffffffff81429006>] ? rest_init+0x7a/0x7c [<ffffffff8177bc8c>] ? start_kernel+0x389/0x394 [<ffffffff8177b29c>] ? x86_64_start_reservations+0xac/0xb0 [<ffffffff8177b384>] ? x86_64_start_kernel+0xe4/0xeb To fix this, the rfcomm_session_put() needs to be moved out of rfcomm_session_timeout() into rfcomm_process_sessions(). In that context it is perfectly fine to sleep and disconnect the socket. Signed-off-by:
Marcel Holtmann <marcel@holtmann.org> Tested-by:
David John <davidjon@xenontk.org> Cc: Chase Douglas <chase.douglas@canonical.com> Signed-off-by:
-
Steven Rostedt authored
commit ea14eb71 upstream. If the graph tracer is active, and a task is forked but the allocating of the processes graph stack fails, it can cause crash later on. This is due to the temporary stack being NULL, but the curr_ret_stack variable is copied from the parent. If it is not -1, then in ftrace_graph_probe_sched_switch() the following: for (index = next->curr_ret_stack; index >= 0; index--) next->ret_stack[index].calltime += timestamp; Will cause a kernel OOPS. Found with Li Zefan's ftrace_stress_test. Signed-off-by:
-
Lai Jiangshan authored
commit 52fbe9cd upstream. The ring buffer resizing and resetting relies on a schedule RCU action. The buffers are disabled, a synchronize_sched() is called and then the resize or reset takes place. But this only works if the disabling of the buffers are within the preempt disabled section, otherwise a window exists that the buffers can be written to while a reset or resize takes place. Reported-by:
-
Bob Copeland authored
commit a951ae21 upstream. The beacon sent gating doesn't seem to work with any combination of flags. Thus, buffered frames tend to stay buffered forever, using up tx descriptors. Instead, use the DBA gating and hold transmission of the buffered frames until 80% of the beacon interval has elapsed using the ready time. This fixes the following error in AP mode: ath5k phy0: no further txbuf available, dropping packet Add a comment to acknowledge that this isn't the best solution. Signed-off-by:
Bob Copeland <me@bobcopeland.com> Acked-by:
Nick Kossifidis <mickflemm@gmail.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
Bob Copeland authored
commit 5d6ce628 upstream When using the external sleep clock in AP mode, the TSF increments too quickly, causing beacon interval to be much lower than it is supposed to be, resulting in lots of beacon-not-ready interrupts. This fixes http://bugzilla.kernel.org/show_bug.cgi?id=14802. Signed-off-by:
-
Jean Delvare authored
commit c074c39d upstream. Experience has shown that the block buffer can only be used for SMBus (not I2C) block transactions, even though the datasheet doesn't mention this limitation. Reported-by:
Felix Rubinstein <felixru@gmail.com> Signed-off-by:
Jean Delvare <khali@linux-fr.org> Cc: Oleg Ryjkov <oryjkov@gmail.com> Signed-off-by:
-
Christoph Fritz authored
commit 31968ecf upstream. ALDI/MEDION netbook E1222 needs to be in the reset quirk list for its touchpad's proper function. Reported-by:
Michael Fischer <mifi@gmx.de> Signed-off-by:
Christoph Fritz <chf.fritz@googlemail.com> Signed-off-by:
Dmitry Torokhov <dtor@mail.ru> Signed-off-by:
-
Thomas Bächler authored
commit eb8bff85 upstream. Signed-off-by:
Thomas Bächler <thomas@archlinux.org> Signed-off-by:
-
john stultz authored
commit ad6759fb upstream. Aaro Koskinen reported an issue in kernel.org bugzilla #15366, where on non-GENERIC_TIME systems, accessing /sys/devices/system/clocksource/clocksource0/current_clocksource results in an oops. It seems the timekeeper/clocksource rework missed initializing the curr_clocksource value in the !GENERIC_TIME case. Thanks to Aaro for reporting and diagnosing the issue as well as testing the fix! Reported-by:
Aaro Koskinen <aaro.koskinen@iki.fi> Signed-off-by:
John Stultz <johnstul@us.ibm.com> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com> LKML-Reference: <1267475683.4216.61.camel@localhost.localdomain> Signed-off-by:
-
Daniel T Chen authored
BugLink: https://bugs.launchpad.net/bugs/538918 The OR has verified that explicitly enabling MSI is necessary for audio to be audible by default. This patch is only applicable to 2.6.32.y; in 2.6.33, MSI is enabled by default. Reported-by:
Sam Townsend <stownsend42@sbcglobal.net> Tested-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
Daniel T Chen <crimsun@ubuntu.com> Signed-off-by:
-
Takashi Iwai authored
commit 5311114d upstream. Since alc_auto_create_input_ctls() doesn't set the elements for the secondary ADCs, "Input Source" elemtns for these also get empty, resulting in buggy outputs of alsactl like: control.14 { comment.access 'read write' comment.type ENUMERATED comment.count 1 iface MIXER name 'Input Source' index 1 value 0 } This patch fixes alc_mux_enum_*() (and others) to fall back to the first entry if the secondary input mux is empty. Signed-off-by:
-
Matt Carlson authored
This is a resubmit backport of commit 92c6b8d1 to kernel version 2.6.32. The gentoo bug report can be found at https://bugs.gentoo.org/show_bug.cgi?id=301091. Thanks to Matt Carlson for his assistance and working me to fix a regression caused by the initial patch. The original description is as follows: The 5906 has trouble with fragments that are less than 8 bytes in size. This patch works around the problem by pivoting the 5906's transmit routine to tg3_start_xmit_dma_bug() and introducing a new SHORT_DMA_BUG flag that enables code to detect and react to the problematic condition. Signed-off-by:
Mike Pagano <mpagano@gentoo.org> Signed-off-by:
Matt Carlson <mcarlson@broadcom.com> Signed-off-by:
Michael Chan <mchan@broadcom.com> Signed-off-by:
-
Louis Rilling authored
commit fe234f0e upstream. Commit 09943a18 Author: Matt Carlson <mcarlson@broadcom.com> Date: Fri Aug 28 14:01:57 2009 +0000 tg3: Convert ISR parameter to tnapi forgot to update tg3_poll_controller(), leading to intermittent crashes with netpoll. Fix this. Signed-off-by:
Louis Rilling <louis.rilling@kerlabs.com> Signed-off-by:
-
David Daney authored
commit abbdc3d8 upstream. commit c8af165342e83a4eb078c9607d29a7c399d30a53 (lmo) rsp. e0cc87f5 (kernel.org) left label_module_alloc unused. Remove it now. Signed-off-by:
David Daney <ddaney@caviumnetworks.com> Cc: linux-mips@linux-mips.org Patchwork: http://patchwork.linux-mips.org/patch/752/Signed-off-by:
Ralf Baechle <ralf@linux-mips.org> Signed-off-by:
-
Russell King authored
commit 98e12b5a upstream. Commit 2552fc27 changed the way the decompressor decides if it is safe to decompress the kernel directly to its final location. Unfortunately, it took the top of the compressed data as being the stack pointer, which it is for ROM=n cases. However, for ROM=y, the stack pointer is not relevant, and results in the wrong answer. Fix this by explicitly storing the end of the biggybacked data in the decompressor, and use that to calculate the compressed image size. Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by:
-
Russell King authored
commit 5ceaa2f3 upstream. The ARM kernel decompressor wants to be able to relocate r/w data independently from the rest of the image, and we do this by ensuring that r/w data has global visibility. Define STATIC_RW_DATA to be empty to achieve this. Signed-off-by:
-
Julia Lawall authored
commit 9b3a6549 upstream. The few lines below the kfree of hdr_buf may go to the label err_free which will also free hdr_buf. The most straightforward solution seems to be to just move the kfree of hdr_buf after these gotos. A simplified version of the semantic match that finds this problem is as follows: (http://coccinelle.lip6.fr/) // <smpl> @r@ identifier E; expression E1; iterator I; statement S; @@ *kfree(E); ... when != E = E1 when != I(E,...) S when != &E *kfree(E); // </smpl> Signed-off-by:
Julia Lawall <julia@diku.dk> Cc: James Bottomley <James.Bottomley@HansenPartnership.com> Signed-off-by:
-
Shaohua Li authored
commit 29874f44 upstream. if no VBT is present, crt_ddc_bus will be left at 0, and cause us to use that for the GPIO register offset. That's never a valid register offset, so let the "undefined" value be 0 instead of -1. Signed-off-by:
Shaohua Li <shaohua.li@intel.com> Signed-off-by:
Zhao Yakui <yakui.zhao@intel.com> Signed-off-by:
Eric Anholt <eric@anholt.net> [anholt: clarified the commit message a bit] Signed-off-by:
-
- 15 Mar, 2010 6 commits
-
-
Greg Kroah-Hartman authored
-
Ian Campbell authored
commit 14315592 upstream. Distros generally (I looked at Debian, RHEL5 and SLES11) seem to enable CONFIG_HIGHPTE for any x86 configuration which has highmem enabled. This means that the overhead applies even to machines which have a fairly modest amount of high memory and which therefore do not really benefit from allocating PTEs in high memory but still pay the price of the additional mapping operations. Running kernbench on a 4G box I found that with CONFIG_HIGHPTE=y but no actual highptes being allocated there was a reduction in system time used from 59.737s to 55.9s. With CONFIG_HIGHPTE=y and highmem PTEs being allocated: Average Optimal load -j 4 Run (std deviation): Elapsed Time 175.396 (0.238914) User Time 515.983 (5.85019) System Time 59.737 (1.26727) Percent CPU 263.8 (71.6796) Context Switches 39989.7 (4672.64) Sleeps 42617.7 (246.307) With CONFIG_HIGHPTE=y but with no highmem PTEs being allocated: Average Optimal load -j 4 Run (std deviation): Elapsed Time 174.278 (0.831968) User Time 515.659 (6.07012) System Time 55.9 (1.07799) Percent CPU 263.8 (71.266) Context Switches 39929.6 (4485.13) Sleeps 42583.7 (373.039) This patch allows the user to control the allocation of PTEs in highmem from the command line ("userpte=nohigh") but retains the status-quo as the default. It is possible that some simple heuristic could be developed which allows auto-tuning of this option however I don't have a sufficiently large machine available to me to perform any particularly meaningful experiments. We could probably handwave up an argument for a threshold at 16G of total RAM. Assuming 768M of lowmem we have 196608 potential lowmem PTE pages. Each page can map 2M of RAM in a PAE-enabled configuration, meaning a maximum of 384G of RAM could potentially be mapped using lowmem PTEs. Even allowing generous factor of 10 to account for other required lowmem allocations, generous slop to account for page sharing (which reduces the total amount of RAM mappable by a given number of PT pages) and other innacuracies in the estimations it would seem that even a 32G machine would not have a particularly pressing need for highmem PTEs. I think 32G could be considered to be at the upper bound of what might be sensible on a 32 bit machine (although I think in practice 64G is still supported). It's seems questionable if HIGHPTE is even a win for any amount of RAM you would sensibly run a 32 bit kernel on rather than going 64 bit. Signed-off-by:
Ian Campbell <ian.campbell@citrix.com> LKML-Reference: <1266403090-20162-1-git-send-email-ian.campbell@citrix.com> Signed-off-by:
-
Thomas Gleixner authored
commit 83ab0aa0 upstream. setscheduler() saves task->sched_class outside of the rq->lock held region for a check after the setscheduler changes have become effective. That might result in checking a stale value. rtmutex_setprio() has the same problem, though it is protected by p->pi_lock against setscheduler(), but for correctness sake (and to avoid bad examples) it needs to be fixed as well. Retrieve task->sched_class inside of the rq->lock held region. Signed-off-by:
Peter Zijlstra <peterz@infradead.org> Signed-off-by:
-
Suresh Siddha authored
commit 9000f05c upstream. Fix a SMT scheduler performance regression that is leading to a scenario where SMT threads in one core are completely idle while both the SMT threads in another core (on the same socket) are busy. This is caused by this commit (with the problematic code highlighted) commit bdb94aa5 Author: Peter Zijlstra <a.p.zijlstra@chello.nl> Date: Tue Sep 1 10:34:38 2009 +0200 sched: Try to deal with low capacity @@ -4203,15 +4223,18 @@ find_busiest_queue() ... for_each_cpu(i, sched_group_cpus(group)) { + unsigned long power = power_of(i); ... - wl = weighted_cpuload(i); + wl = weighted_cpuload(i) * SCHED_LOAD_SCALE; + wl /= power; - if (rq->nr_running == 1 && wl > imbalance) + if (capacity && rq->nr_running == 1 && wl > imbalance) continue; On a SMT system, power of the HT logical cpu will be 589 and the scheduler load imbalance (for scenarios like the one mentioned above) can be approximately 1024 (SCHED_LOAD_SCALE). The above change of scaling the weighted load with the power will result in "wl > imbalance" and ultimately resulting in find_busiest_queue() return NULL, causing load_balance() to think that the load is well balanced. But infact one of the tasks can be moved to the idle core for optimal performance. We don't need to use the weighted load (wl) scaled by the cpu power to compare with imabalance. In that condition, we already know there is only a single task "rq->nr_running == 1" and the comparison between imbalance, wl is to make sure that we select the correct priority thread which matches imbalance. So we really need to compare the imabalnce with the original weighted load of the cpu and not the scaled load. But in other conditions where we want the most hammered(busiest) cpu, we can use scaled load to ensure that we consider the cpu power in addition to the actual load on that cpu, so that we can move the load away from the guy that is getting most hammered with respect to the actual capacity, as compared with the rest of the cpu's in that busiest group. Fix it. Reported-by:
Ma Ling <ling.ma@intel.com> Initial-Analysis-by:
Zhang, Yanmin <yanmin_zhang@linux.intel.com> Signed-off-by:
-
Vaidyanathan Srinivasan authored
commit 28f53181 upstream. Fix for sched_mc_powersavigs for pre-Nehalem platforms. Child sched domain should clear SD_PREFER_SIBLING if parent will have SD_POWERSAVINGS_BALANCE because they are contradicting. Sets the flags correctly based on sched_mc_power_savings. Signed-off-by:
Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com> Signed-off-by:
-
Gleb Natapov authored
commit e92805ac upstream. Add CPL checking in case emulator is tricked into emulating privilege instruction from userspace. Signed-off-by:
Gleb Natapov <gleb@redhat.com> Signed-off-by:
Avi Kivity <avi@redhat.com> Signed-off-by:
-
