On Thu, Sep 28, 2017 at 5:26 AM, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
>
> Commit 33fc30b47098 (cpufreq: intel_pstate: Document the current
> behavior and user interface) dropped the intel-pstate.txt file
> from Documentation/cpu-freq/, but it did not update the index.txt
> file in t
On 10/01/2017 12:29 PM, Jonathan Cameron wrote:
On Thu, 28 Sep 2017 14:50:12 +0200
Maciej Purski wrote:
Max expected current is used for calculating calibration register value,
Current LSB and Power LSB according to equations found in ina datasheet.
Max expected current is now implicitly set
On Mon, Oct 02, 2017 at 11:14:46AM -0700, Mathieu Poirier wrote:
> On 19 September 2017 at 21:46, 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 doe
On Tue 03-10-17 07:35:59, Tejun Heo wrote:
> Hello, Michal.
>
> On Tue, Oct 03, 2017 at 04:22:46PM +0200, Michal Hocko wrote:
> > On Tue 03-10-17 15:08:41, Roman Gushchin wrote:
> > > On Tue, Oct 03, 2017 at 03:36:23PM +0200, Michal Hocko wrote:
> > [...]
> > > > I guess we want to inherit the val
It is possible to use nested structs like:
struct {
struct {
void *arg1;
} st1, st2, *st3, st4;
};
Handling it requires to split each parameter. Change the logic
to allow such definitions.
In order to test the new nested logic, the following file
was used to test
Right now, if one uses "--rst" instead of "-rst", it just
ignore the argument and produces a man page. Change the
logic to accept both "-cmd" and "--cmd". Also, if
"cmd" doesn't exist, print the usage information and exit.
Signed-off-by: Mauro Carvalho Chehab
---
scripts/kernel-doc | 34
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 a/Documentation/doc-guide/k
The check_sections() function has a $nested parameter, meant
to identify when a nested struct is present. As we now have
a logic that handles it, get rid of such parameter.
Suggested-by: Markus Heiser
Signed-off-by: Mauro Carvalho Chehab
---
scripts/kernel-doc | 19 ---
1 file c
Right now, if kernel-doc is called without arguments, it
defaults to man pages. IMO, it makes more sense to
default to ReST, as this is the output that it is most
used nowadays, and it easier to check if everything got
parsed fine on an enriched text mode format.
Signed-off-by: Mauro Carvalho Cheh
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 ++
1 file changed, 30 insertio
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
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
---
Documentation/doc-guide/kernel-doc.rst | 48 +---
Now that kernel-doc can hanle nested structs/unions, describe
such fields at w1_netlink_message_types.
Acked-by: Evgeniy Polyakov
Signed-off-by: Mauro Carvalho Chehab
---
drivers/w1/w1_netlink.h | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/w1/w1_netlink.h b/d
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
Sphinx has a hard time dealing with tabs, causing it to
misinterpret paragraph continuation.
As we're now mainly focused on supporting ReST output,
replace tabs by spaces, in order to avoid troubles when
the output is parsed by Sphinx.
Signed-off-by: Mauro Carvalho Chehab
---
scripts/kernel-doc
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 +++---
1 file chang
Function arguments are different than usual ones. So, an
special logic is needed in order to handle such arguments
on nested structs.
Signed-off-by: Mauro Carvalho Chehab
---
scripts/kernel-doc | 38 ++
1 file changed, 26 insertions(+), 12 deletions(-)
diff -
Right now, it is not possible to document nested struct and nested unions.
kernel-doc simply ignore them.
Add support to document them.
Patches 1 to 6 improve kernel-doc documentation to reflect what
kernel-doc currently supports and import some stuff from the
old kernel-doc-nano-HOWTO.txt.
Pat
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),
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 -
1
The logic at create_parameterlist()'s ancillary push_parameter()
function has already a way to output the declaration name, with
would help to discover what declaration is missing.
However, currently, the logic is utterly broken, as it uses
the var $type with a wrong meaning. With the current code
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 | 34 ++
1 file changed, 34 insertions(+)
diff --git
On Tue, Oct 03, 2017 at 04:22:46PM +0200, Michal Hocko wrote:
> On Tue 03-10-17 15:08:41, Roman Gushchin wrote:
> > On Tue, Oct 03, 2017 at 03:36:23PM +0200, Michal Hocko wrote:
> [...]
> > > I guess we want to inherit the value on the memcg creation but I agree
> > > that enforcing parent setting
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 co
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 beh
Document the cgroup-aware OOM killer.
Signed-off-by: Roman Gushchin
Cc: Michal Hocko
Cc: Vladimir Davydov
Cc: Johannes Weiner
Cc: Tetsuo Handa
Cc: Andrew Morton
Cc: David Rientjes
Cc: Tejun Heo
Cc: kernel-t...@fb.com
Cc: cgro...@vger.kernel.org
Cc: linux-doc@vger.kernel.org
Cc: linux-ker..
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
Cc: Vladimir Davydov
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 cgro
This patchset makes the OOM killer cgroup-aware.
v10:
- Separate oom_group introduction into a standalone patch
- Stop propagating oom_group
- Make oom_group delegatable
- Do not try to kill the biggest task in the first order,
if the whole cgroup is going to be killed
- Stop caching
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 pr
On Wed, 4 Oct 2017 08:40:32 -0700
Jakub Kicinski wrote:
> Add documentation for bpftool. Separate files for each subcommand.
> Use rst format. Documentation is compiled into man pages using
> rst2man.
>
> Signed-off-by: David Beckett
> Signed-off-by: Jakub Kicinski
> Acked-by: Alexei Starov
On Wed, Oct 04, 2017 at 04:46:33PM +0100, Roman Gushchin wrote:
> 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 SI
On Wed, Oct 04, 2017 at 04:46:34PM +0100, Roman Gushchin wrote:
> 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
On Wed, Oct 04, 2017 at 04:46:35PM +0100, 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:
>
>
On Wed, Oct 04, 2017 at 04:46:36PM +0100, Roman Gushchin wrote:
> 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 memor
> +
> +static void select_victim_memcg(struct mem_cgroup *root, struct oom_control
> *oc)
> +{
> + struct mem_cgroup *iter;
> +
> + oc->chosen_memcg = NULL;
> + oc->chosen_points = 0;
> +
> + /*
> +* The oom_score is calculated for leaf memory cgroups (including
> +
On Wed, Oct 04, 2017 at 03:27:20PM -0400, Johannes Weiner wrote:
> On Wed, Oct 04, 2017 at 04:46:35PM +0100, 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.
> >
> > Th
On Wed, 4 Oct 2017 20:36:42 +0200, Jesper Dangaard Brouer wrote:
> On Wed, 4 Oct 2017 08:40:32 -0700
> Jakub Kicinski wrote:
>
> > Add documentation for bpftool. Separate files for each subcommand.
> > Use rst format. Documentation is compiled into man pages using
> > rst2man.
> >
> > Signed-
On Wed, Oct 04, 2017 at 04:46:37PM +0100, Roman Gushchin wrote:
> 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
On Wed, Oct 04, 2017 at 04:46:38PM +0100, Roman Gushchin wrote:
> Document the cgroup-aware OOM killer.
>
> Signed-off-by: Roman Gushchin
> Cc: Michal Hocko
> Cc: Vladimir Davydov
> Cc: Johannes Weiner
> Cc: Tetsuo Handa
> Cc: Andrew Morton
> Cc: David Rientjes
> Cc: Tejun Heo
> Cc: kernel
On Wed, 4 Oct 2017, Roman Gushchin wrote:
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index d5f3a62887cf..b4de17a78dc1 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -917,7 +917,8 @@ static void invalidate_reclaim_iterators(struct
> mem_cgroup *dead_memcg)
> * value, the fun
On Wed, Oct 04, 2017 at 12:48:03PM -0700, Shakeel Butt wrote:
> > +
> > +static void select_victim_memcg(struct mem_cgroup *root, struct
> > oom_control *oc)
> > +{
> > + struct mem_cgroup *iter;
> > +
> > + oc->chosen_memcg = NULL;
> > + oc->chosen_points = 0;
> > +
> > +
On Wed, 4 Oct 2017, Roman Gushchin wrote:
> > > @@ -828,6 +828,12 @@ static void __oom_kill_process(struct task_struct
> > > *victim)
> > > struct mm_struct *mm;
> > > bool can_oom_reap = true;
> > >
> > > + if (is_global_init(victim) || (victim->flags & PF_KTHREAD) ||
> > > + victim->s
On Wed, Oct 04, 2017 at 01:17:14PM -0700, David Rientjes wrote:
> On Wed, 4 Oct 2017, Roman Gushchin wrote:
>
> > > > @@ -828,6 +828,12 @@ static void __oom_kill_process(struct task_struct
> > > > *victim)
> > > > struct mm_struct *mm;
> > > > bool can_oom_reap = true;
> > > >
>
On Wed, 4 Oct 2017, Roman Gushchin wrote:
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index b4de17a78dc1..79f30c281185 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -2670,6 +2670,178 @@ static inline bool memcg_has_children(struct
> mem_cgroup *memcg)
> return ret;
> }
On Wed, Oct 04, 2017 at 01:17:14PM -0700, David Rientjes wrote:
> On Wed, 4 Oct 2017, Roman Gushchin wrote:
>
> > > > @@ -828,6 +828,12 @@ static void __oom_kill_process(struct task_struct
> > > > *victim)
> > > > struct mm_struct *mm;
> > > > bool can_oom_reap = true;
> > > >
>
On Wed, Oct 04, 2017 at 01:27:14PM -0700, David Rientjes wrote:
> By only considering leaf memcgs, does this penalize users if their memcg
> becomes oc->chosen_memcg purely because it has aggregated all of its
> processes to be members of that memcg, which would otherwise be the
> standard behav
>> > + if (memcg_has_children(iter))
>> > + continue;
>>
>> && iter != root_mem_cgroup ?
>
> Oh, sure. I had a stupid bug in my test script, which prevented me from
> catching this. Thanks!
>
> This should fix the problem.
> --
> diff --git a/mm/memcontrol.c b/mm
Hi,
On Tue, Oct 3, 2017 at 9:05 PM, Masahiro Yamada
wrote:
> Thanks for the patches. The idea is interesting.
>
> I am not a Chrome developer, but cc-option could be improved somehow.
>
>
> I examined two approaches to mitigate the pain.
>
> [1] Skip cc-option completely when we run non-build ta
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 w
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 we
Add section for resultant frequency during GPU workloads.
Signed-off-by: Srinivas Pandruvada
---
Documentation/admin-guide/pm/intel_pstate.rst | 19 +++
1 file changed, 19 insertions(+)
diff --git a/Documentation/admin-guide/pm/intel_pstate.rst
b/Documentation/admin-guide/pm/in
On Thu, Sep 28, 2017 at 12:22:13PM -0700, David Lin wrote:
> On Wed, Sep 27, 2017 at 10:43 PM, Dmitry Torokhov
> wrote:
> >>One thing I noticed is that input_ff_create_memless() also does not
> >>use high-resolution timer hence it also does not have the stop-time
> >>precision that I'm looking for
On Wed, Oct 4, 2017 at 3:37 PM, Douglas Anderson wrote:
> 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 com
Add documentation for bpftool. Separate files for each subcommand.
Use rst format. Documentation is compiled into man pages using
rst2man.
Signed-off-by: David Beckett
Signed-off-by: Jakub Kicinski
Acked-by: Alexei Starovoitov
Acked-by: Daniel Borkmann
---
CC: linux-doc@vger.kernel.org
too
55 matches
Mail list logo
