aboutsummaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* tuna: update defconfigsZiyan2015-01-152-8/+40
| | | | | | | - enable Memory Resource Controller for Control Groups - enable tracer Change-Id: I8fe414599e8a730caec5da25585a87094190a2b0
* oom: do not kill tasks with oom_score_adj OOM_SCORE_ADJ_MINMichal Hocko2015-01-151-0/+5
| | | | | | | | | | | | | | | | | | | | | | | Commit c9f01245 ("oom: remove oom_disable_count") has removed the oom_disable_count counter which has been used for early break out from oom_badness so we could never select a task with oom_score_adj set to OOM_SCORE_ADJ_MIN (oom disabled). Now that the counter is gone we are always going through heuristics calculation and we always return a non zero positive value. This means that we can end up killing a task with OOM disabled because it is indistinguishable from regular tasks with 1% resp. CAP_SYS_ADMIN tasks with 3% usage of memory or tasks with oom_score_adj set but OOM enabled. Let's break out early if the task should have OOM disabled. Signed-off-by: Michal Hocko <mhocko@suse.cz> Acked-by: David Rientjes <rientjes@google.com> Acked-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> Cc: Oleg Nesterov <oleg@redhat.com> Cc: Ying Han <yinghan@google.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* oom: remove oom_disable_countDavid Rientjes2015-01-156-49/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | This removes mm->oom_disable_count entirely since it's unnecessary and currently buggy. The counter was intended to be per-process but it's currently decremented in the exit path for each thread that exits, causing it to underflow. The count was originally intended to prevent oom killing threads that share memory with threads that cannot be killed since it doesn't lead to future memory freeing. The counter could be fixed to represent all threads sharing the same mm, but it's better to remove the count since: - it is possible that the OOM_DISABLE thread sharing memory with the victim is waiting on that thread to exit and will actually cause future memory freeing, and - there is no guarantee that a thread is disabled from oom killing just because another thread sharing its mm is oom disabled. Signed-off-by: David Rientjes <rientjes@google.com> Reported-by: Oleg Nesterov <oleg@redhat.com> Reviewed-by: Oleg Nesterov <oleg@redhat.com> Cc: Ying Han <yinghan@google.com> Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* oom: avoid killing kthreads if they assume the oom killed thread's mmDavid Rientjes2015-01-151-2/+3
| | | | | | | | | | | | | | | | | | | | After selecting a task to kill, the oom killer iterates all processes and kills all other threads that share the same mm_struct in different thread groups. It would not otherwise be helpful to kill a thread if its memory would not be subsequently freed. A kernel thread, however, may assume a user thread's mm by using use_mm(). This is only temporary and should not result in sending a SIGKILL to that kthread. This patch ensures that only user threads and not kthreads are sent a SIGKILL if they share the same mm_struct as the oom killed task. Signed-off-by: David Rientjes <rientjes@google.com> Reviewed-by: Michal Hocko <mhocko@suse.cz> Reviewed-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* memcg: add memory.pressure_level eventsAnton Vorontsov2015-01-137-5/+533
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With this patch userland applications that want to maintain the interactivity/memory allocation cost can use the pressure level notifications. The levels are defined like this: The "low" level means that the system is reclaiming memory for new allocations. Monitoring this reclaiming activity might be useful for maintaining cache level. Upon notification, the program (typically "Activity Manager") might analyze vmstat and act in advance (i.e. prematurely shutdown unimportant services). The "medium" level means that the system is experiencing medium memory pressure, the system might be making swap, paging out active file caches, etc. Upon this event applications may decide to further analyze vmstat/zoneinfo/memcg or internal memory usage statistics and free any resources that can be easily reconstructed or re-read from a disk. The "critical" level means that the system is actively thrashing, it is about to out of memory (OOM) or even the in-kernel OOM killer is on its way to trigger. Applications should do whatever they can to help the system. It might be too late to consult with vmstat or any other statistics, so it's advisable to take an immediate action. The events are propagated upward until the event is handled, i.e. the events are not pass-through. Here is what this means: for example you have three cgroups: A->B->C. Now you set up an event listener on cgroups A, B and C, and suppose group C experiences some pressure. In this situation, only group C will receive the notification, i.e. groups A and B will not receive it. This is done to avoid excessive "broadcasting" of messages, which disturbs the system and which is especially bad if we are low on memory or thrashing. So, organize the cgroups wisely, or propagate the events manually (or, ask us to implement the pass-through events, explaining why would you need them.) Performance wise, the memory pressure notifications feature itself is lightweight and does not require much of bookkeeping, in contrast to the rest of memcg features. Unfortunately, as of current memcg implementation, pages accounting is an inseparable part and cannot be turned off. The good news is that there are some efforts[1] to improve the situation; plus, implementing the same, fully API-compatible[2] interface for CONFIG_CGROUP_MEM_RES_CTLR=n case (e.g. embedded) is also a viable option, so it will not require any changes on the userland side. [1] http://permalink.gmane.org/gmane.linux.kernel.cgroups/6291 [2] http://lkml.org/lkml/2013/2/21/454 Change-Id: Ib7b9f7986008d423b84152e2781d0402a560c95e [akpm@linux-foundation.org: coding-style fixes] [akpm@linux-foundation.org: fix CONFIG_CGROPUPS=n warnings] Signed-off-by: Anton Vorontsov <anton.vorontsov@linaro.org> Acked-by: Kirill A. Shutemov <kirill@shutemov.name> Acked-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Cc: Tejun Heo <tj@kernel.org> Cc: David Rientjes <rientjes@google.com> Cc: Pekka Enberg <penberg@kernel.org> Cc: Mel Gorman <mgorman@suse.de> Cc: Glauber Costa <glommer@parallels.com> Cc: Michal Hocko <mhocko@suse.cz> Cc: Luiz Capitulino <lcapitulino@redhat.com> Cc: Greg Thelen <gthelen@google.com> Cc: Leonid Moiseichuk <leonid.moiseichuk@nokia.com> Cc: KOSAKI Motohiro <kosaki.motohiro@gmail.com> Cc: Minchan Kim <minchan@kernel.org> Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Cc: John Stultz <john.stultz@linaro.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Conflicts: mm/memcontrol.c mm/vmscan.c
* dss: update variable names to reflect kernel changesZiyan2015-01-131-2/+2
| | | | Change-Id: I4c66e9825dce4e41fc11477ee40af5e16191db5f
* DSS: Fixed compilation warnings at device.c:504Ievgen Musiichuk2015-01-131-1/+2
| | | | | | | | | | | Warning: comparison of distinct pointer types lacks a cast Changed clamp macro to clamp_t with __u32 type Change-Id: I1ab6169a79e8dfdfb2e3b87147e225382a64248d Signed-off-by: Ievgen Musiichuk <ievgen.musiichuk@ti.com> Conflicts: drivers/video/omap2/dsscomp/device.c
* Revert "Revert "DSSCOMP: Added UV buffer user-space address to the API""Pavel Nedev2015-01-131-2/+6
| | | | | | | | | | This reverts commit 2ca61536d413af33d9ef58db249a327991f62a79. Change-Id: I9d00daf95698b14d5029a49f3802400e8f60d4da Signed-off-by: Pavel Nedev <pnedev@mm-sol.com> Conflicts: include/video/dsscomp.h
* mmc: quirks: Disable optimization on eMMC firmware patching if needed.Kyle Repinski2015-01-121-0/+11
| | | | | | | | | | | GCC 4.8 and above are breaking this code, even with as little as -Og. Signed-off-by: Kyle Repinski <repinski23@gmail.com> Conflicts: drivers/mmc/core/quirks.c Change-Id: Id165084ce96dfd825440b45dae8fc93230ce2862
* Revert "[REVIEW ME] tuna: temporary fix for gcc 4.8 build breakage"Ziyan2015-01-121-3/+0
| | | | This reverts commit f747c7de8f5a03987e9044dd56f2349b47e20bdc.
* Revert "OMAP: DSS2: Support for Samsung AMS452GN05"Ziyan2015-01-121-25/+0
| | | | This reverts commit 968b17621a48a4ea5049968d3601f59624f33dd3.
* OMAP: DSS: Add device latency constraintGilles-Arnaud Bleu-Laine2015-01-121-0/+10
| | | | | | | | | | | | Request a latency constraint on PM framework for DSS before cutting module clocks. Release the request upon enabling the clocks. Change-Id: If257218a3cb8c3ea0d8451421f87e0a9ba199bb5 Signed-off-by: Gilles-Arnaud Bleu-Laine <gilles@ti.com> Conflicts: drivers/video/omap2/dss/dispc.c
* OMAP: DSS: add support DPI panel for Panda in waitforvsyncVince Kim2015-01-121-12/+42
| | | | | | | | | | | | Panda board uses DPI interace for DVI, and vsync IRQ for DPI panel is added to avoid timeout. As adding DPI pannel support, if...else statement is re-written with switch statement. Other non-supported panels are added in switch statement as place holer. Change-Id: Ic383acd55245e86579a29bb04cfd50334df0e133 Signed-off-by: Vince Kim <vince.kim@ti.com>
* OMAP4: DSS: Fix to consider DSI manual update mode in waitforvsyncSunita Nadampalli2015-01-121-3/+11
| | | | | | | | | | | Add checks for manual update mode of DSI, and wait for framedone interrupt in case of manual update mode. Change-Id: I143a8d457219e2dab59ef099bab5c31043a36da0 Signed-off-by: Sunita Nadampalli <sunitan@ti.com> Conflicts: drivers/video/omap2/dss/manager.c
* power: max17040: add support for POWER_SUPPLY_PROP_CHARGE_ENABLEDZiyan2015-01-101-0/+4
| | | | Change-Id: Ied641d29a7258a069811e51383cdbf7be06bc0e7
* power: power_supply: add POWER_SUPPLY_PROP_CHARGE_ENABLEDTodd Poynor2014-12-242-0/+2
| | | | | | | | | Change-Id: I3e93b502452811cbfc4d904202b4f1d94edc143d Signed-off-by: Todd Poynor <toddpoynor@google.com> Conflicts: drivers/power/power_supply_sysfs.c include/linux/power_supply.h
* tuna: enable 512 MHz GPU frequency slotZiyan2014-12-233-0/+10
| | | | Change-Id: I859ed2cbb777dadc01be95ecf56b333f8940e848
* power: max17040: add support for POWER_SUPPLY_PROP_PRESENTZiyan2014-12-201-0/+2
| | | | Change-Id: I7a05757b875bbab57f043d0afa364d475df7771d
* tuna: add cyanogenmod defconfigZiyan2014-12-161-0/+2802
| | | | | | To separate some non-stock features. Change-Id: Ic0a43d5b2c3399ff5ce1e0e56f98bf179ae6cb31
* tuna: update defconfigZiyan2014-12-161-14/+4
| | | | Change-Id: I1819e9b22c40f3fa875929f20672cc5b1d23e3dd
* Added Color Control version 4.Ezekeel2014-12-165-0/+279
| | | | | | | Conflicts: drivers/misc/Makefile Change-Id: Ie57d33003d1ce0a750ef2ec2cb15884a449df92a
* Add sysfs vibrator intensity controlscodeworkx2014-12-161-2/+78
| | | | | | | | | | | | | Patch Set 2 Removed unused variable Patch Set 3 Use pwm_old variable Patch Set 4 Add authorship Change-Id: Ibcb887fe2c78cfd5740f363d33d1ed997c98b9c6
* optimized LPDDR RAM timings (~10% throughput increase)Boy Petersen2014-12-161-9/+9
| | | | | | | | | | | | | | | Tweaked the device's RAM timings. Benchmarks suggest a 10 percent thorughput improvement (RgBandwidth RAM misc benchmark; threads: 1. 20 benchmark instances each, best result wins): Stock Tweaked Copy 1249.9 MB/s -> 1373.0 MB/s --> 9.86 % improvement Scale 1084.8 MB/s -> 1188.1 MB/s --> 9.52 % improvement Add 938.4 MB/s -> 1050.2 MB/s --> 11.91 % improvement Triad 923.0 MB/s -> 1043.5 MB/s --> 13.06 % improvement Change-Id: I082e7515d2995910b115c3fe0283fe25808d1cfb
* ASoC: add back generic SDP4430 board fileZiyann2014-12-062-3/+1174
| | | | Just to be in sync with p-android-omap-3.0-dev.
* ASoC: Tuna: separate tuna board fileZiyann2014-12-064-61/+58
|
* ASoC: sdp4430: Correct stream name for FM BE DAIManjunatha Halli2014-12-061-1/+1
| | | | | | | | Correct stream name for OMAP_ABE_BE_MM_EXT0 backend DAI Change-Id: I7e29dbda5a35f35a614fc45f3f7e3172444f89be Signed-off-by: Manjunatha Halli <x0130808@ti.com> Signed-off-by: Axel Castaneda Gonzalez <x0055901@ti.com>
* ASoC: OMAP PCM: Remove combined ABE/HDMI constraintMisael Lopez Cruz2014-12-051-9/+0
| | | | | | | | Remove buffer bytes constraint used for ABE and HDMI in favor of individual, separate constraints applied by each driver. Change-Id: Ic1b0aefff6504159f36eb701b91e5e3e7c78d688 Signed-off-by: Misael Lopez Cruz <misael.lopez@ti.com>
* ASoC: twl6040: VDDHF as SUPPLY widgetMisael Lopez Cruz2014-12-051-0/+39
| | | | | | | | | | | VDDHF external boost supply was being enabled after and disabled before handsfree driver as a strategy for pop noise reduction. This strategy makes handsfree driver very susceptible to overcurrent events, so the boost supply is converted to a SUPPLY widget to enable it before and disable it after handsfree path. Change-Id: I608b4b0f5cb3301053869ccd2732434efe276b81 Signed-off-by: Misael Lopez Cruz <misael.lopez@ti.com>
* ASoC: twl6040: Add VDDHF regulatorGirish S Ghongdemath2014-12-052-0/+35
| | | | | | | | | | | | | | | | | | | | Use regulator framework to enable/disable VDDHF voltage supply for handsfree drivers. Not providing a valid regulator for VDDHF through regulator framework doesn't have any negative impact as long as VDDHF is actually supplied by some other way (e.g. voltage supply enabled through bootloader or machine initialization). Ported from p-android-omap-2.6.35 Change-Id: I9df90a695ed9afcb6da916fb53bb3965c5292226 Signed-off-by: Girish S G <girishsg@ti.com> Signed-off-by: Misael Lopez Cruz <misael.lopez@ti.com> Signed-off-by: Akash Choudhari <akashc@ti.com> Signed-off-by: Girish S Ghongdemath <girishsg@ti.com> Signed-off-by: Gabriel M. Beddingfield <gabrbedd@ti.com> Conflicts: sound/soc/codecs/twl6040.c
* ASoC: TWL6040: Adding Aux audio outputIsrael Cepeda2014-12-051-0/+17
| | | | | | | | Adding switch controls to enable/disable audio output throught Aux pins in codec. Change-Id: I329c44fe95a9157d56017ac47cb4e091e87d8710 Signed-off-by: Israel Cepeda <icepeda@ti.com>
* ASoC: twl6040: Handle handsfree overcurrent eventsMisael Lopez Cruz2014-12-052-1/+40
| | | | | | | | | | | | | | | | TWL6040 has a short circuit detection mechanism that report events when the current exceeds 2.2A in its handsfree output stage. Upon detection of handsfree overcurrent, the suggested action is to disable handsfree drivers to prevent damage. Additionally, when this event occurs it's reported to Android userspace layers through an uEvent associated with the TWL6040 MFD. Change-Id: Iea94c55286a9adb158caac10f7a15fae73827792 Signed-off-by: Misael Lopez Cruz <misael.lopez@ti.com> Signed-off-by: Chris Kelly <c-kelly@ti.com> Conflicts: sound/soc/codecs/twl6040.c
* ASoC: twl6040: Add wakelock for headset detection interruptMisael Lopez Cruz2014-12-051-1/+9
| | | | | | | | | | | | | | | | | | TWL6040 is kept active during a voice call, but CPU can go into suspend state. If headset is inserted or removed while the CPU is in suspend, SYS_NIRQ2 IRQ line will wake the CPU up and the headset state will be acknowledged at kernel level, but the event propagated to userspace layers to cause audio rerouting might not be completed on-time before CPU goes back to suspend. A wakelock is added to prevent CPU to go back to suspend immediately after the event, instead it'll wait for 2 secs for the event to be processed in userspace. Change-Id: I88a71345c7a082801a21335f20c920c68bacb8fc Signed-off-by: Misael Lopez Cruz <misael.lopez@ti.com> Conflicts: sound/soc/codecs/twl6040.c
* ASoC: twl6040: Align widget names with Kernel V3.1Pierre Moos2014-12-041-20/+20
| | | | | | | | | Change-Id: I77acb512c8d8bd703d10cdfab4397d5ffdbb2fb6 Signed-off-by: Pierre Moos <p-moos@ti.com> Signed-off-by: Francois Mazard <f-mazard@ti.com> Conflicts: sound/soc/codecs/twl6040.c
* staging: android: lowmemorykiller: fix build breakage on kernel 3.0Ziyann2014-11-291-1/+1
|
* lowmemorykiller: make default lowmemorykiller debug message usefulColin Cross2014-11-291-8/+20
| | | | | | | | | | | | | | | | | | | | | lowmemorykiller debug messages are inscrutable and mostly useful for debugging the lowmemorykiller, not explaining why a process was killed. Make the messages more useful by prefixing them with "lowmemorykiller: " and explaining in more readable terms what was killed, who it was killed for, and why it was killed. The messages now look like: [ 76.997631] lowmemorykiller: Killing 'droid.gallery3d' (2172), adj 1000, [ 76.997635] to free 27436kB on behalf of 'kswapd0' (29) because [ 76.997638] cache 122624kB is below limit 122880kB for oom_score_adj 1000 [ 76.997641] Free memory is -53356kB above reserved A negative number for free memory above reserved means some of the reserved memory has been used and is being regenerated by kswapd, which is likely what called the shrinkers. Change-Id: I1fe983381e73e124b90aa5d91cb66e55eaca390f Signed-off-by: Colin Cross <ccross@android.com>
* staging: android: lowmemorykiller: Change default debug_level to 1Arve Hjønnevåg2014-11-291-1/+1
| | | | | | | | | | The select...to kill messages are not very useful when not debugging the lowmemorykiller itself. After the change to check TIF_MEMDIE instead of using a task notifer this message can also get very noisy. Change-Id: Ice171c25801d6faa454b885a23b24b002423b754 Signed-off-by: Arve Hjønnevåg <arve@android.com>
* staging: android: lowmemorykiller: Don't count reserved free memoryArve Hjønnevåg2014-11-291-1/+2
| | | | | | | | | The amount of reserved memory varies between devices. Subtract it here to reduce the amount of devices specific tuning needed for the minfree values. Change-Id: I466ae8b18f5972f6f6d8b5a7d8c4ae69660de53a Signed-off-by: Arve Hjønnevåg <arve@android.com>
* staging: android: lowmemorykiller: Add config option to support oom_adj valuesArve Hjønnevåg2014-11-292-0/+94
| | | | | | | | | | | | | The conversion to use oom_score_adj instead of the deprecated oom_adj values breaks existing user-space code. Add a config option to convert oom_adj values written to oom_score_adj values if they appear to be valid oom_adj values. Change-Id: I68308125059b802ee2991feefb07e9703bc48549 Signed-off-by: Arve Hjønnevåg <arve@android.com> Conflicts: drivers/staging/android/Kconfig
* android, lowmemorykiller: remove task handoff notifierDavid Rientjes2014-11-291-33/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The task handoff notifier leaks task_struct since it never gets freed after the callback returns NOTIFY_OK, which means it is responsible for doing so. It turns out the lowmemorykiller actually doesn't need this notifier at all. It's used to prevent unnecessary killing by waiting for a thread to exit as a result of lowmem_shrink(), however, it's possible to do this in the same way the kernel oom killer works by setting TIF_MEMDIE and avoid killing if we're still waiting for it to exit. The kernel oom killer will already automatically set TIF_MEMDIE for threads that are attempting to allocate memory that have a fatal signal. The thread selected by lowmem_shrink() will have such a signal after the lowmemorykiller sends it a SIGKILL, so this won't result in an unnecessary use of memory reserves for the thread to exit. This has the added benefit that we don't have to rely on CONFIG_PROFILING to prevent needlessly killing tasks. Reported-by: Werner Landgraf <w.landgraf@ru.ru> Cc: stable@vger.kernel.org Signed-off-by: David Rientjes <rientjes@google.com> Acked-by: Colin Cross <ccross@android.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Conflicts: drivers/staging/android/lowmemorykiller.c
* Staging: android: lowmemorykiller.cGreg Kroah-Hartman2014-11-291-1/+1
| | | | | | | Fix compiler warning about the type of the module parameter. Cc: San Mehat <san@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* staging: android, lowmemorykiller: convert to use oom_score_adjDavid Rientjes2014-11-291-21/+22
| | | | | | | | | | | | | /proc/pid/oom_adj is deprecated and will be removed in August 2012 according to Documentation/feature-removal-schedule.txt. Convert its usage in the lowmemorykiller to use the new interface, oom_score_adj, instead. Signed-off-by: David Rientjes <rientjes@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Conflicts: drivers/staging/android/lowmemorykiller.c
* staging: android/lowmemorykiller: Do not kill kernel threadsAnton Vorontsov2014-11-291-0/+3
| | | | | | | | | | LMK should not try killing kernel threads. Suggested-by: Oleg Nesterov <oleg@redhat.com> Reviewed-by: Oleg Nesterov <oleg@redhat.com> Signed-off-by: Anton Vorontsov <anton.vorontsov@linaro.org> Acked-by: KOSAKI Motohiro <kosaki.motohiro@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* staging: android/lowmemorykiller: No need for task->signal checkAnton Vorontsov2014-11-291-7/+1
| | | | | | | | | | task->signal == NULL is not possible, so no need for these checks. Suggested-by: Oleg Nesterov <oleg@redhat.com> Reviewed-by: Oleg Nesterov <oleg@redhat.com> Signed-off-by: Anton Vorontsov <anton.vorontsov@linaro.org> Acked-by: KOSAKI Motohiro <kosaki.motohiro@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* staging: android/lowmemorykiller: Better mm handlingAnton Vorontsov2014-11-291-7/+9
| | | | | | | | | | | | | | LMK should not directly check for task->mm. The reason is that the process' threads may exit or detach its mm via use_mm(), but other threads may still have a valid mm. To catch this we use find_lock_task_mm(), which walks up all threads and returns an appropriate task (with lock held). Suggested-by: Oleg Nesterov <oleg@redhat.com> Reviewed-by: Oleg Nesterov <oleg@redhat.com> Signed-off-by: Anton Vorontsov <anton.vorontsov@linaro.org> Acked-by: KOSAKI Motohiro <kosaki.motohiro@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* staging: android/lowmemorykiller: Don't grab tasklist_lockAnton Vorontsov2014-11-291-3/+4
| | | | | | | | | | | | | | | | | | | | | | Grabbing tasklist_lock has its disadvantages, i.e. it blocks process creation and destruction. If there are lots of processes, blocking doesn't sound as a great idea. For LMK, it is sufficient to surround tasks list traverse with rcu_read_{,un}lock(). >From now on using force_sig() is not safe, as it can race with an already exiting task, so we use send_sig() now. As a downside, it won't kill PID namespace init processes, but that's not what we want anyway. Suggested-by: Oleg Nesterov <oleg@redhat.com> Signed-off-by: Anton Vorontsov <anton.vorontsov@linaro.org> Reviewed-by: Oleg Nesterov <oleg@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Conflicts: drivers/staging/android/lowmemorykiller.c
* Staging: android: fixed 80 characters warnings in lowmemorykiller.cMarco Navarra2014-11-291-6/+6
| | | | | | | This patch fixes some 80 chatacters limit warnings in the lowmemorykiller.c file Signed-off-by: Marco Navarra <fromenglish@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* add extra free kbytes tunableRik van Riel2014-11-293-7/+50
| | | | | | | | | | | | | | | | | | | | | | | | | Add a userspace visible knob to tell the VM to keep an extra amount of memory free, by increasing the gap between each zone's min and low watermarks. This is useful for realtime applications that call system calls and have a bound on the number of allocations that happen in any short time period. In this application, extra_free_kbytes would be left at an amount equal to or larger than than the maximum number of allocations that happen in any burst. It may also be useful to reduce the memory use of virtual machines (temporarily?), in a way that does not cause memory fragmentation like ballooning does. [ccross] Revived for use on old kernels where no other solution exists. The tunable will be removed on kernels that do better at avoiding direct reclaim. Change-Id: I765a42be8e964bfd3e2886d1ca85a29d60c3bb3e Signed-off-by: Rik van Riel<riel@redhat.com> Signed-off-by: Colin Cross <ccross@android.com>
* net: ipv6: Add a sysctl to make optimistic addresses useful candidatesErik Kline2014-11-283-2/+59
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add a sysctl that causes an interface's optimistic addresses to be considered equivalent to other non-deprecated addresses for source address selection purposes. Preferred addresses will still take precedence over optimistic addresses, subject to other ranking in the source address selection algorithm. This is useful where different interfaces are connected to different networks from different ISPs (e.g., a cell network and a home wifi network). The current behaviour complies with RFC 3484/6724, and it makes sense if the host has only one interface, or has multiple interfaces on the same network (same or cooperating administrative domain(s), but not in the multiple distinct networks case. For example, if a mobile device has an IPv6 address on an LTE network and then connects to IPv6-enabled wifi, while the wifi IPv6 address is undergoing DAD, IPv6 connections will try use the wifi default route with the LTE IPv6 address, and will get stuck until they time out. Also, because optimistic nodes can receive frames, issue an RTM_NEWADDR as soon as DAD starts (with the IFA_F_OPTIMSTIC flag appropriately set). A second RTM_NEWADDR is sent if DAD completes (the address flags have changed), otherwise an RTM_DELADDR is sent. Also: add an entry in ip-sysctl.txt for optimistic_dad. [backport of net-next 7fd2561e4ebdd070ebba6d3326c4c5b13942323f] Signed-off-by: Erik Kline <ek@google.com> Acked-by: Lorenzo Colitti <lorenzo@google.com> Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org> Signed-off-by: David S. Miller <davem@davemloft.net> Bug: 17769720 Change-Id: I440a9b8c788db6767d191bbebfd2dff481aa9e0d
* tuna: remove fb1 and update tiler carveout accordinglyZiyann2014-11-281-2/+2
| | | | Credit to @MWisBest
* net: ipv6: autoconf routes into per-device tablesLorenzo Colitti2014-11-274-44/+103
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, IPv6 router discovery always puts routes into RT6_TABLE_MAIN. This causes problems for connection managers that want to support multiple simultaneous network connections and want control over which one is used by default (e.g., wifi and wired). To work around this connection managers typically take the routes they prefer and copy them to static routes with low metrics in the main table. This puts the burden on the connection manager to watch netlink to see if the routes have changed, delete the routes when their lifetime expires, etc. Instead, this patch adds a per-interface sysctl to have the kernel put autoconf routes into different tables. This allows each interface to have its own autoconf table, and choosing the default interface (or using different interfaces at the same time for different types of traffic) can be done using appropriate ip rules. The sysctl behaves as follows: - = 0: default. Put routes into RT6_TABLE_MAIN as before. - > 0: manual. Put routes into the specified table. - < 0: automatic. Add the absolute value of the sysctl to the device's ifindex, and use that table. The automatic mode is most useful in conjunction with net.ipv6.conf.default.accept_ra_rt_table. A connection manager or distribution could set it to, say, -100 on boot, and thereafter just use IP rules. Change-Id: I093d39fb06ec413905dc0d0d5792c1bc5d5c73a9 Signed-off-by: Lorenzo Colitti <lorenzo@google.com> Conflicts: net/ipv6/addrconf.c net/ipv6/route.c
generated by cgit v1.1 at 2025-01-25 12:35:25 +0000