Re: [v8 0/4] cgroup-aware OOM killer

I'm excited to see this being discussed again - it's been years since the last attempt. I've tried to stay out of the conversation, but I feel obligated say something and then go back to lurking. On Tue, Sep 26, 2017 at 10:26 AM, Johannes Weiner wrote: > On Tue, Sep 26, 2017

Re: [PATCH v2] scripts: kernel-doc: fix nexted handling

Hi Mauro, [auto build test WARNING on linus/master] [also build test WARNING on v4.14-rc2 next-20170926] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Mauro-Carvalho-Chehab/scripts-kernel-doc

Re: [PATCH 07/10] docs: kernel-doc.rst: add documentation about man pages

On 09/26/17 10:59, Mauro Carvalho Chehab wrote: > kernel-doc-nano-HOWTO.txt has a chapter about man pages > production. While we don't have a working "make manpages" > target, add it. > > Signed-off-by: Mauro Carvalho Chehab > --- >

Re: [PATCH 02/10] docs: kernel-doc.rst: better describe kernel-doc arguments

On 09/26/17 10:59, Mauro Carvalho Chehab wrote: > Add a new section to describe kernel-doc arguments, > adding examples about how identation should happen, as failing > to do that causes Sphinx to do the wrong thing. > > Signed-off-by: Mauro Carvalho Chehab > --- >

[lwn:docs-next 9/9] htmldocs: include/net/cfg80211.h:3278: warning: Excess enum value 'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'

tree: git://git.lwn.net/linux-2.6 docs-next head: 5cb5c31cdf246099f7d48a57f448b05b7941cd6a commit: 5cb5c31cdf246099f7d48a57f448b05b7941cd6a [9/9] scripts/kernel-doc: warn on excess enum value descriptions reproduce: make htmldocs All warnings (new ones prefixed by >>): WARNING:

Re: [v8 0/4] cgroup-aware OOM killer

On Tue, 26 Sep 2017, Michal Hocko wrote: > > No, I agree that we shouldn't compare sibling memory cgroups based on > > different criteria depending on whether group_oom is set or not. > > > > I think it would be better to compare siblings based on the same criteria > > independent of group_oom

Re: [PATCH 09/10] scripts: kernel-doc: parse next structs/unions

Em Tue, 26 Sep 2017 14:59:19 -0300 Mauro Carvalho Chehab escreveu: > There are several places within the Kernel tree with nested > structs/unions, like this one: > > struct ingenic_cgu_clk_info { > const char *name; > enum { > CGU_CLK_NONE = 0, >

Re: [PATCH] scripts: kernel-doc: parse next structs/unions

Em Tue, 26 Sep 2017 18:56:10 +0200 Markus Heiser escreveu: > > Am 25.09.2017 um 20:22 schrieb Mauro Carvalho Chehab > > : > > > > Jon, > > > > Please let me know what you think about this approach. IMHO, it is a way > > better than what we

Re: [PATCH v2] scripts: kernel-doc: fix nexted handling

Em Tue, 26 Sep 2017 14:45:08 +0200 Markus Heiser escreveu: > > Am 25.09.2017 um 20:41 schrieb Mauro Carvalho Chehab > > : > > >>> + $cont = 1; > >>> + }; > >>> + }; > >>> + # Ignore other nested elements, like enums

[PATCH 10/10] [RFC] w1_netlink.h: add support for nested structs

Describe nested struct/union fields NOTE: This is a pure test patch, meant to validate if the parsing logic for nested structs is working properly. I've no idea if the random text I added there is correct! Signed-off-by: Mauro Carvalho Chehab ---

[PATCH 01/10] scripts: kernel-doc: get rid of unused output formats

Since there isn't any docbook code anymore upstream, we can get rid of several output formats: - docbook/xml, html, html5 and list formats were used by the old build system; - As ReST is text, there's not much sense on outputting on a different text format. After this patch, only man and rst

[PATCH 05/10] docs: kernel-doc.rst: improve structs chapter

There is a mess on this chapter: it suggests that even enums and unions should be documented with "struct". That's not the way it should be ;-) Fix it and move it to happen earlier. Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Mauro Carvalho Chehab

[PATCH 09/10] scripts: kernel-doc: parse next structs/unions

There are several places within the Kernel tree with nested structs/unions, like this one: struct ingenic_cgu_clk_info { const char *name; enum { CGU_CLK_NONE = 0, CGU_CLK_EXT = BIT(0), CGU_CLK_PLL = BIT(1), CGU_CLK_GATE = BIT(2), CGU_CLK_MUX = BIT(3),

[PATCH 00/10] kernel-doc: add supported to document nested structs/unions

Right now, it is not possible to document nested struct and nested unions. kernel-doc simply ignore them. Add support to document them. This series starts with a patch getting rid of the now unused output formats for kernel-doc: since we got rid of all DocBook stuff, we should not need them

[PATCH 06/10] docs: kernel-doc: improve typedef documentation

Add documentation about typedefs for function prototypes and move it to happen earlier. Signed-off-by: Mauro Carvalho Chehab --- Documentation/doc-guide/kernel-doc.rst | 32 ++-- 1 file changed, 22 insertions(+), 10 deletions(-) diff --git

[PATCH 04/10] docs: kernel-doc.rst: improve function documentation section

Move its contents to happen earlier and improve the description of return values, adding a subsection to it. Most of the contents there came from kernel-doc-nano-HOWTO.txt. Signed-off-by: Mauro Carvalho Chehab --- Documentation/doc-guide/kernel-doc.rst | 100

[PATCH 08/10] docs: get rid of kernel-doc-nano-HOWTO.txt

Everything there is already described at Documentation/doc-guide/kernel-doc.rst. So, there's no reason why to keep it anymore. Signed-off-by: Mauro Carvalho Chehab --- Documentation/00-INDEX | 2 - Documentation/kernel-doc-nano-HOWTO.txt | 322

[PATCH 03/10] docs: kernel-doc.rst: improve private members description

The private members section can now be moved to be together with the arguments section. Move it there and add an example about the usage of public: Signed-off-by: Mauro Carvalho Chehab --- Documentation/doc-guide/kernel-doc.rst | 56 ++

[PATCH 07/10] docs: kernel-doc.rst: add documentation about man pages

kernel-doc-nano-HOWTO.txt has a chapter about man pages production. While we don't have a working "make manpages" target, add it. Signed-off-by: Mauro Carvalho Chehab --- Documentation/doc-guide/kernel-doc.rst | 61 ++ 1 file changed,

[PATCH 02/10] docs: kernel-doc.rst: better describe kernel-doc arguments

Add a new section to describe kernel-doc arguments, adding examples about how identation should happen, as failing to do that causes Sphinx to do the wrong thing. Signed-off-by: Mauro Carvalho Chehab --- Documentation/doc-guide/kernel-doc.rst | 44

[RFC PATCH 0/2] kbuild: Cache exploratory calls to the compiler

This two-patch series attempts to speed incremental builds of the kernel up by a bit. How much of a speedup you get depends a lot on your environment, specifically the speed of your workstation and how fast it takes to invoke the compiler. In the Chrome OS build environment you get a really big

[RFC PATCH 1/2] kbuild: Add a cache for generated variables

While timing a "no-op" build of the kernel (incrementally building the kernel even though nothing changed) in the Chrome OS build system I found that it was much slower than I expected. Digging into things a bit, I found that quite a bit of the time was spent invoking the C compiler even though

Re: [v8 0/4] cgroup-aware OOM killer

On Tue, Sep 26, 2017 at 03:30:40PM +0200, Michal Hocko wrote: > On Tue 26-09-17 13:13:00, Roman Gushchin wrote: > > On Tue, Sep 26, 2017 at 01:21:34PM +0200, Michal Hocko wrote: > > > On Tue 26-09-17 11:59:25, Roman Gushchin wrote: > > > > On Mon, Sep 25, 2017 at 10:25:21PM +0200, Michal Hocko

Re: [PATCH] scripts: kernel-doc: parse next structs/unions

> Am 25.09.2017 um 20:22 schrieb Mauro Carvalho Chehab > : > > Jon, > > Please let me know what you think about this approach. IMHO, it is a way > better than what we do right now. This is more a proof of concept, as the > patch is not complete. > > With it, we can

Re: [v8 0/4] cgroup-aware OOM killer

On Tue 26-09-17 13:13:00, Roman Gushchin wrote: > On Tue, Sep 26, 2017 at 01:21:34PM +0200, Michal Hocko wrote: > > On Tue 26-09-17 11:59:25, Roman Gushchin wrote: > > > On Mon, Sep 25, 2017 at 10:25:21PM +0200, Michal Hocko wrote: > > > > On Mon 25-09-17 19:15:33, Roman Gushchin wrote: > > > >

Re: [PATCH 3/3 v12] printk: Add monotonic, boottime, and realtime timestamps

On 09/26/2017 07:48 AM, Petr Mladek wrote: > On Mon 2017-09-18 13:51:00, 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: [PATCH v2] scripts: kernel-doc: fix nexted handling

> Am 25.09.2017 um 20:41 schrieb Mauro Carvalho Chehab > : >>> + $cont = 1; >>> + }; >>> + }; >>> + # Ignore other nested elements, like enums >>> + $members =~ s/({[^\{\}]*})//g; >>> + $nested = $decl_type; >> >> What is the

Re: [v8 0/4] cgroup-aware OOM killer

On Tue, Sep 26, 2017 at 01:21:34PM +0200, Michal Hocko wrote: > On Tue 26-09-17 11:59:25, Roman Gushchin wrote: > > On Mon, Sep 25, 2017 at 10:25:21PM +0200, Michal Hocko wrote: > > > On Mon 25-09-17 19:15:33, Roman Gushchin wrote: > > > [...] > > > > I'm not against this model, as I've said

Re: [PATCH 3/3 v12] printk: Add monotonic, boottime, and realtime timestamps

On Mon 2017-09-18 13:51:00, 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,

Re: [v8 0/4] cgroup-aware OOM killer

On Mon, Sep 25, 2017 at 10:25:21PM +0200, Michal Hocko wrote: > On Mon 25-09-17 19:15:33, Roman Gushchin wrote: > [...] > > I'm not against this model, as I've said before. It feels logical, > > and will work fine in most cases. > > > > In this case we can drop any mount/boot options, because it

Re: [v8 0/4] cgroup-aware OOM killer

On Mon 25-09-17 15:21:03, David Rientjes wrote: > On Mon, 25 Sep 2017, Johannes Weiner wrote: > > > > True but we want to have the semantic reasonably understandable. And it > > > is quite hard to explain that the oom killer hasn't selected the largest > > > memcg just because it happened to be