Doc.../sound/soc/platform.rst: snd_soc_platform_driver out of sync

Hi maintainers of Sound and/or Docs. Documentation/sound/soc/platform.rst quotes outdated definition of "struct snd_soc_platform_driver". I spotted this because it shows like there are suspend/resume function pointers while this is no longer true. I don't have a good idea how to update the doc,

Re: [PATCH v13 0/7] cgroup-aware OOM killer

On Thu, 30 Nov 2017 15:28:17 + Roman Gushchin wrote: > This patchset makes the OOM killer cgroup-aware. Thanks, I'll grab these. There has been controversy over this patchset, to say the least. I can't say that I followed it closely! Could those who still have reservations

Re: [PATCH v3] doc: add maintainer book

On Thu, Nov 30, 2017 at 09:06:21AM -0200, Mauro Carvalho Chehab wrote: > Em Thu, 30 Nov 2017 21:47:44 +1100 > "Tobin C. Harding" escreveu: > > > On Thu, Nov 30, 2017 at 07:01:19AM -0200, Mauro Carvalho Chehab wrote: > > > Em Thu, 30 Nov 2017 12:55:07 +1100 > > > "Tobin C. Harding"

[PATCH v13 4/7] mm, oom: introduce memory.oom_group

The cgroup-aware OOM killer treats leaf memory cgroups as memory consumption entities and performs the victim selection by comparing them based on their memory footprint. Then it kills the biggest task inside the selected memory cgroup. But there are workloads, which are not tolerant to a such

[PATCH v13 6/7] mm, oom, docs: describe the cgroup-aware OOM killer

Document the cgroup-aware OOM killer. Signed-off-by: Roman Gushchin Cc: Johannes Weiner Cc: Michal Hocko Cc: Vladimir Davydov Cc: Tetsuo Handa Cc: Andrew Morton

[PATCH v13 7/7] cgroup: list groupoom in cgroup features

List groupoom in cgroup features list (exported via /sys/kernel/cgroup/features), which can be used by a userspace apps (most likely, systemd) to get an idea which cgroup features are supported by kernel. Signed-off-by: Roman Gushchin Cc: Tejun Heo Cc: Michal Hocko

[PATCH v13 5/7] mm, oom: add cgroup v2 mount option for cgroup-aware OOM killer

Add a "groupoom" cgroup v2 mount option to enable the cgroup-aware OOM killer. If not set, the OOM selection is performed in a "traditional" per-process way. The behavior can be changed dynamically by remounting the cgroupfs. Signed-off-by: Roman Gushchin Cc: Michal Hocko

[PATCH v13 2/7] mm: implement mem_cgroup_scan_tasks() for the root memory cgroup

Implement mem_cgroup_scan_tasks() functionality for the root memory cgroup to use this function for looking for a OOM victim task in the root memory cgroup by the cgroup-ware OOM killer. The root memory cgroup is treated as a leaf cgroup, so only tasks which are directly belonging to the root

[PATCH v13 0/7] cgroup-aware OOM killer

This patchset makes the OOM killer cgroup-aware. v13: - Reverted fallback to per-process OOM as in v11 (asked by Michal) - Added entry in cgroup features list - Added a note about charge migration - Rebase v12: - Root memory cgroup is evaluated based on sum of the oom scores of

[PATCH v13 1/7] mm, oom: refactor the oom_kill_process() function

The oom_kill_process() function consists of two logical parts: the first one is responsible for considering task's children as a potential victim and printing the debug information. The second half is responsible for sending SIGKILL to all tasks sharing the mm struct with the given victim. This

[PATCH] kernel-doc: parse DECLARE_KFIFO_PTR()

On media, we now have an struct declared with: struct lirc_fh { struct list_head list; struct rc_dev *rc; int carrier_low; boolsend_timeout_reports; DECLARE_KFIFO_PTR(rawir, unsigned int);

RE: [PATCH v2] MIPS: Add nonxstack=on|off kernel parameter

Hi James, > > We do have PT_GNU_STACK flags set correctly, this feature is required to > > workaround CPU revisions which do not have RIXI support. > > RIXI support can be discovered programatically from CP0_Config3.RXI > (cpu_has_rixi in asm/cpu-features.h), so I don't follow why CPUs without >

Re: [PATCH v3] doc: add maintainer book

Em Thu, 30 Nov 2017 21:47:44 +1100 "Tobin C. Harding" escreveu: > On Thu, Nov 30, 2017 at 07:01:19AM -0200, Mauro Carvalho Chehab wrote: > > Em Thu, 30 Nov 2017 12:55:07 +1100 > > "Tobin C. Harding" escreveu: > > > +So, by way of an example, Greg gives; a pull

Re: [PATCH v3] doc: add maintainer book

On Thu, Nov 30, 2017 at 07:01:19AM -0200, Mauro Carvalho Chehab wrote: > Em Thu, 30 Nov 2017 12:55:07 +1100 > "Tobin C. Harding" escreveu: > > > There is currently very little documentation in the kernel on maintainer > > level tasks. In particular there are no documents on

Re: [PATCH v2] MIPS: Add nonxstack=on|off kernel parameter

On Thu, Nov 30, 2017 at 09:34:15AM +, Miodrag Dinic wrote: > Hi David, > > Sorry for a late response, please find answers in-lined: > > > > If this parameter is omitted, kernel behavior remains the same as it > > > was before this patch is applied. > > > > Do other architectures have a

RE: [PATCH v2] MIPS: Add nonxstack=on|off kernel parameter

Hi David, Sorry for a late response, please find answers in-lined: > > If this parameter is omitted, kernel behavior remains the same as it > > was before this patch is applied. > > Do other architectures have a similar hack? > > If arm{,64} and x86 don't need this, what would make MIPS so

Re: [PATCH v3] doc: add maintainer book

Em Thu, 30 Nov 2017 12:55:07 +1100 "Tobin C. Harding" escreveu: > There is currently very little documentation in the kernel on maintainer > level tasks. In particular there are no documents on creating pull > requests to submit to Linus. > > Quoting Greg Kroah-Hartman on LKML: >