Re: [v6 2/4] mm, oom: cgroup-aware OOM killer

On Wed, 23 Aug 2017, Roman Gushchin wrote: > Traditionally, the OOM killer is operating on a process level. > Under oom conditions, it finds a process with the highest oom score > and kills it. > > This behavior doesn't suit well the system with many running > containers: > > 1) There is no

Re: [v5 2/4] mm, oom: cgroup-aware OOM killer

On Wed, 23 Aug 2017, Roman Gushchin wrote: > > It's better to have newbies consult the documentation once than making > > everybody deal with long and cumbersome names for the rest of time. > > > > Like 'ls' being better than 'read_and_print_directory_contents'. > > I don't think it's a good

[PATCH v2] docs: ReSTify table of contents in core.rst

Sphinx will now generate the table of contents automatically, which avoids having the ToC getting out of sync with the rest of the document. Signed-off-by: Josh Holland --- Documentation/security/keys/core.rst | 12 +--- 1 file changed, 1 insertion(+), 11

Re: [PATCH 1/2] docs: Standardise capitalisation of section headers in core.rst

On 2017-08-21, Jonathan Corbet wrote: > On Mon, 21 Aug 2017 12:15:26 +0300 > Jani Nikula wrote: > > > However, if you want to sphinxify things a little, you could make the > > resulting html a little bit nicer with automatic links, and document > > maintenance a

Re: [PATCH 2/2 v7] printk: Add monotonic, boottime, and realtime timestamps

On Wed, Aug 23, 2017 at 11:31 AM, Prarit Bhargava wrote: > On 08/23/2017 04:45 AM, Petr Mladek wrote: >> I know that it would make the code more complicated. But >> I really like the approach used by /sys/power/disk or >> /sys/power/pm_test. They list all possible values >> and

Re: [PATCH 2/2 v7] printk: Add monotonic, boottime, and realtime timestamps

On 08/23/2017 04:45 AM, Petr Mladek wrote: > On Thu 2017-08-17 09:15:39, Prarit Bhargava wrote: >> printk.time=1/CONFIG_PRINTK_TIME=1 adds a unmodified local hardware clock >> timestamp to printk messages. The local hardware clock loses time each >> day making it difficult to determine exactly

Re: [v5 2/4] mm, oom: cgroup-aware OOM killer

On Wed, Aug 23, 2017 at 01:24:41PM -0400, Johannes Weiner wrote: > Hi, > > On Wed, Aug 23, 2017 at 05:20:31PM +0100, Roman Gushchin wrote: > > On Tue, Aug 22, 2017 at 01:03:44PM -0400, Johannes Weiner wrote: > > > > + css_task_iter_start(>css, 0, ); > > > > + while ((task =

Re: [v5 2/4] mm, oom: cgroup-aware OOM killer

Hi, On Wed, Aug 23, 2017 at 05:20:31PM +0100, Roman Gushchin wrote: > On Tue, Aug 22, 2017 at 01:03:44PM -0400, Johannes Weiner wrote: > > > + css_task_iter_start(>css, 0, ); > > > + while ((task = css_task_iter_next())) { > > > + /* > > > + * If there are no tasks, or all tasks

[v6 0/4] cgroup-aware OOM killer

This patchset makes the OOM killer cgroup-aware. v6: - Renamed oom_control.chosen to oom_control.chosen_task - Renamed oom_kill_all_tasks to oom_kill_all - Per-node NR_SLAB_UNRECLAIMABLE accounting - Several minor fixes and cleanups - Docs updated v5: - Rebased on top of Michal

[v6 3/4] mm, oom: introduce oom_priority for memory cgroups

Introduce a per-memory-cgroup oom_priority setting: an integer number within the [-1, 1] range, which defines the order in which the OOM killer selects victim memory cgroups. OOM killer prefers memory cgroups with larger priority if they are populated with eligible tasks. The

[v6 2/4] mm, oom: cgroup-aware OOM killer

Traditionally, the OOM killer is operating on a process level. Under oom conditions, it finds a process with the highest oom score and kills it. This behavior doesn't suit well the system with many running containers: 1) There is no fairness between containers. A small container with few large

[v6 4/4] mm, oom, docs: describe the cgroup-aware OOM killer

Update cgroups v2 docs. Signed-off-by: Roman Gushchin Cc: Michal Hocko Cc: Vladimir Davydov Cc: Johannes Weiner Cc: Tetsuo Handa Cc: David Rientjes Cc: Tejun

[v6 1/4] 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

Re: [v5 2/4] mm, oom: cgroup-aware OOM killer

Hi Johannes! Thank you for review! I do agree with most of the comments, and I will address them in v6. I'll post it soon. Please, find some comments below. On Tue, Aug 22, 2017 at 01:03:44PM -0400, Johannes Weiner wrote: > Hi Roman, > > great work! This looks mostly good to me now. Below are

Re: [PATCH] doc: coresight: correct usage for '/dev/cpu_dma_latency'

On Wed, 23 Aug 2017 15:23:18 +0800 Leo Yan wrote: > Cc: Kim Phillips > Reported-by: Kim Phillips Thanks; typically only the latter is needed. > Set latency request to /dev/cpu_dma_latency to disable all CPUs specific idle >

Re: [PATCH RFC] media: open.rst: document devnode-centric and mc-centric types

Em Wed, 23 Aug 2017 12:37:30 +0300 Sakari Ailus escreveu: > Hi Mauro, > > Thanks for the patch! Something like this was long due. > > I cc'd Hans and Laurent to get their attention, too. > > On Sat, Aug 19, 2017 at 07:04:40AM -0300, Mauro Carvalho Chehab wrote: > > When

Re: [v5 1/4] mm, oom: refactor the oom_kill_process() function

On Tue, Aug 22, 2017 at 01:06:55PM -0400, Johannes Weiner wrote: > On Mon, Aug 14, 2017 at 07:32:09PM +0100, Roman Gushchin wrote: > > @@ -817,67 +817,12 @@ static bool task_will_free_mem(struct task_struct > > *task) > > return ret; > > } > > > > -static void oom_kill_process(struct

Re: [PATCH] doc: coresight: correct usage for '/dev/cpu_dma_latency'

Hi Sudeep, On Wed, Aug 23, 2017 at 10:17:06AM +0100, Sudeep Holla wrote: > > On 23/08/17 08:23, Leo Yan wrote: > > In the coresight CPU debug document it suggests to use 'echo' command > > to set latency request to /dev/cpu_dma_latency so can disable all CPU > > idle states, but in fact this

Re: [PATCH RFC] media: open.rst: document devnode-centric and mc-centric types

Hi Mauro, Thanks for the patch! Something like this was long due. I cc'd Hans and Laurent to get their attention, too. On Sat, Aug 19, 2017 at 07:04:40AM -0300, Mauro Carvalho Chehab wrote: > When we added support for omap3, back in 2010, we added a new > type of V4L2 devices that aren't fully

Re: [PATCH] doc: coresight: correct usage for '/dev/cpu_dma_latency'

On 23/08/17 08:23, Leo Yan wrote: > In the coresight CPU debug document it suggests to use 'echo' command > to set latency request to /dev/cpu_dma_latency so can disable all CPU > idle states, but in fact this doesn't work. > > This is because when the command 'echo' exits, it releases the

[PATCH v2 0/4] Fix problems with PDF output with Sphinx 1.6

This series have a few patches that fix Sphinx 1.6 builds. I've sent two of those patches before, individually, but it was not clear who should merge it. So, I ended by splitting the first patch into two ones: one touching just at the media book, and the last one touching Sphinx documentation and

[PATCH v2 1/4] media: fix pdf build with Spinx 1.6

Sphinx 1.6 generates some LaTeX code before each table, starting its own environment before calling tabulary, apparently to improve table layout. The problem is that such environment is incompatible with adjustbox. While, in thesis, it should be possible to override it or to redefine tabulary, I

[PATCH v2 2/4] media: dev-sliced-vbi.rst: fix verbatim font size on a table

On Sphinx 1.6, verbatim font is always \small. That causes a problem inside Sliced VBI services table, as it is too big for the box. Signed-off-by: Mauro Carvalho Chehab --- Documentation/media/uapi/v4l/dev-sliced-vbi.rst | 3 +++ 1 file changed, 3 insertions(+) diff

[PATCH v2 4/4] docs-rst: Allow Sphinx version 1.6

Now that the PDF building issues with Sphinx 1.6 got fixed, update the documentation and scripts accordingly. Signed-off-by: Mauro Carvalho Chehab --- Documentation/conf.py | 3 --- Documentation/doc-guide/sphinx.rst | 4 +--- scripts/sphinx-pre-install

[PATCH v2 3/4] docs-rst: pdf: use same vertical margin on all Sphinx versions

Currently, on Sphinx up to version 1.4, pdf output uses a vertical margin of 1 inch. For upper versions, it uses a margin of 0.5 inches. That causes both page headers and footers to be very close to the margin of the sheet. Not all printers support writing like that. Also, there's no reason why

Re: [PATCH 2/2 v7] printk: Add monotonic, boottime, and realtime timestamps

On Thu 2017-08-17 09:15:39, Prarit Bhargava wrote: > printk.time=1/CONFIG_PRINTK_TIME=1 adds a unmodified local hardware clock > timestamp to printk messages. The local hardware clock loses time each > day making it difficult to determine exactly when an issue has occurred in > the kernel log,

[PATCH] doc: coresight: correct usage for '/dev/cpu_dma_latency'

In the coresight CPU debug document it suggests to use 'echo' command to set latency request to /dev/cpu_dma_latency so can disable all CPU idle states, but in fact this doesn't work. This is because when the command 'echo' exits, it releases the device node's file descriptor and the kernel

[PATCH] docs-rst: pdf: use same vertical margin on all Sphinx versions

Currently, on Sphinx up to version 1.4, pdf output uses a vertical margin of 1 inch. For upper versions, it uses a margin of 0.5 inches. That causes both page headers and footers to be very close to the margin of the sheet. Not all printers support writing like that. Also, there's no reason why