On Thu, Oct 19, 2017 at 12:50 AM, Qixuan Wu wrote:
> Hi All,
>
> Currently, squashfs fragments' cache size is only determined by
> config option CONFIG_SQUASHFS_FRAGMENT_CACHE_SIZE. Users have
> no way to change the value when they get the binary kernel.
Thank-you for the patches, but they're bot
[...]
> In this regards as we consider genpd being a trivial PM domain, those
> examples your bring up above is too me also examples of trivial PM
> domains. Especially because they don't deal with wakeups, as that is
> taken care of by the drivers, right!?
Not directly,
On 20 October 2017 at 03:19, Rafael J. Wysocki wrote:
> On Thursday, October 19, 2017 2:21:07 PM CEST Ulf Hansson wrote:
>> On 19 October 2017 at 00:12, Rafael J. Wysocki wrote:
>> > On Wednesday, October 18, 2017 4:11:33 PM CEST Ulf Hansson wrote:
>> >> [...]
>> >>
>> >> >>
>> >> >> The reason w
Hi,
On Wed, Oct 18, 2017 at 9:45 AM, Masahiro Yamada
wrote:
> 2017-10-14 3:02 GMT+09:00 Douglas Anderson :
>> Right now there is a way to add some CFLAGS that affect target builds,
>> but no way to add CFLAGS that affect host builds. Let's add a way.
>> We'll document two environment variables:
GPIO state reset tolerance is implemented in gpiolib through the
addition of a new pinconf parameter. With that, some renaming of helpers
is done to clarify the scope of the already existing
gpiochip_line_is_persistent(), as it's now ambiguous as to whether that
means on suspend, reset or both. Thi
Add flags and the associated flag mappings between interfaces to enable
GPIO reset tolerance to be specified via devicetree.
Signed-off-by: Andrew Jeffery
---
drivers/gpio/gpiolib-of.c | 2 ++
drivers/gpio/gpiolib.c | 5 +
include/dt-bindings/gpio/gpio.h | 4
include/linu
Similar to devicetree support, add flags and mappings to expose reset
tolerance configuration through the chardev interface.
Signed-off-by: Andrew Jeffery
---
drivers/gpio/gpiolib.c| 14 +-
include/uapi/linux/gpio.h | 11 ++-
2 files changed, 19 insertions(+), 6 deletions
Expose a new 'maintain' sysfs attribute to control both suspend and
reset tolerance.
Signed-off-by: Andrew Jeffery
---
Documentation/gpio/sysfs.txt | 9 +
drivers/gpio/gpiolib-sysfs.c | 88 ++--
2 files changed, 93 insertions(+), 4 deletions(-)
diff
Use the new pinconf parameter for reset tolerance to expose the
associated capability of the Aspeed GPIO controller.
Signed-off-by: Andrew Jeffery
---
drivers/gpio/gpio-aspeed.c | 39 +--
1 file changed, 37 insertions(+), 2 deletions(-)
diff --git a/drivers/g
Hello,
This series exposes a "reset tolerant" property for GPIOs. For example, the
controller implemented in Aspeed BMCs provides such a feature to allow the BMC
to be reset whilst maintaining necessary state to keep host systems alive or
status LEDs in-tact.
I'm sending it as an RFC because I'm
Hi Mark/Will,
Thanks.
On 2017/10/19 23:32, Mark Rutland wrote:
> On Thu, Oct 19, 2017 at 04:28:35PM +0100, Will Deacon wrote:
>> On Thu, Oct 19, 2017 at 01:29:18PM +0100, Mark Rutland wrote:
>>> Will, are you happy to queue this?
>>>
>>> There's a minor fixup [1] needed in patch 2, but otherwise
On Thursday, October 19, 2017 2:21:07 PM CEST Ulf Hansson wrote:
> On 19 October 2017 at 00:12, Rafael J. Wysocki wrote:
> > On Wednesday, October 18, 2017 4:11:33 PM CEST Ulf Hansson wrote:
> >> [...]
> >>
> >> >>
> >> >> The reason why pm_runtime_force_* needs to respects the hierarchy of
> >> >
On 09/28/2017 05:43 PM, Calvin Owens wrote:
Not all consoles are created equal: depending on the actual hardware,
the latency of a printk() call can vary dramatically. The worst examples
are serial consoles, where it can spin for tens of milliseconds banging
the UART to emit a message, which can
Because many of RCU's files have not been included into docbook, a
number of errors have accumulated. This commit fixes them.
Signed-off-by: Paul E. McKenney
---
include/linux/rculist.h | 2 +-
include/linux/rcupdate.h | 22 ++
include/linux/srcu.h | 1 +
kernel/rcu/s
Commit 764f80798b95 ("doc: Add RCU files to docbook-generation files")
added :external: options for RCU source files in the file
Documentation/core-api/kernel-api.rst. However, this now means
nothing, so this commit removes them.
Reported-by: Randy Dunlap
Reported-by: Akira Yokosawa
Signed-off-
On 10/19/2017 01:11 PM, Ulf Hansson wrote:
> On 19 October 2017 at 20:04, Ulf Hansson wrote:
>> On 19 October 2017 at 19:21, Grygorii Strashko
>> wrote:
>>>
>>>
>>> On 10/19/2017 03:33 AM, Ulf Hansson wrote:
On 18 October 2017 at 23:48, Rafael J. Wysocki wrote:
> On Wednesday, Octobe
Because many of RCU's files have not been included into docbook, a
number of errors have accumulated. This commit fixes them.
Signed-off-by: Paul E. McKenney
---
include/linux/rculist.h | 2 +-
include/linux/rcupdate.h | 22 ++
include/linux/srcu.h | 1 +
kernel/rcu/s
Commit 764f80798b95 ("doc: Add RCU files to docbook-generation files")
added :external: options for RCU source files in the file
Documentation/core-api/kernel-api.rst. However, this now means
nothing, so this commit removes them.
Reported-by: Randy Dunlap
Reported-by: Akira Yokosawa
Signed-off-
Hello, Linus,
Commit 764f80798b95 ("doc: Add RCU files to docbook-generation files"),
which is in v4.14-rc1, added :external: options for RCU source files
in the file Documentation/core-api/kernel-api.rst. However, this now
means nothing, and furthermore breaks builds of the docbook, which has
le
On Thu 19-10-17 15:45:34, Johannes Weiner wrote:
> On Thu, Oct 19, 2017 at 07:52:12PM +0100, Roman Gushchin wrote:
> > This patchset makes the OOM killer cgroup-aware.
>
> Hi Andrew,
>
> I believe this code is ready for merging upstream, and it seems Michal
> is in agreement. There are two main t
On Thu, Oct 19, 2017 at 07:52:12PM +0100, Roman Gushchin wrote:
> This patchset makes the OOM killer cgroup-aware.
Hi Andrew,
I believe this code is ready for merging upstream, and it seems Michal
is in agreement. There are two main things to consider, however.
David would have really liked for
On Thu 19-10-17 19:52:15, 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
On Mon, 16 Oct 2017 16:32:51 -0700
Randy Dunlap wrote:
> There are some good comments about bitmap operations in lib/bitmap.c
> and include/linux/bitmap.h, so format them for document generation and
> pull them into core-api/kernel-api.rst.
>
> I converted the "tables" of functions from using ta
On Thu, 12 Oct 2017 15:23:26 -0500
Tom Saeger wrote:
> Batch (2) set of simple document ref fixes.
>
>
> Tom Saeger (8):
> Documentation: fix locking rt-mutex doc refs
> Documentation: fix ref to sphinx/kerneldoc.py
> Documentation: fix ref to workqueue content
> Documentation: fix ref
>>> Something like:
>>>
>>> "because there is a dump_stack() done on allocation failures
>>> without __GFP_JNOWARN"
>>
>> How do you think about to convert such a description into a special format
>> for further reference documentation?
>
> I think it's a bad idea if it's a "special" format.
Wil
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
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
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
On Sun, 15 Oct 2017 11:24:08 +0200
Julia Lawall wrote:
> There is no Coccinelle version 1.2. 1.0.2 must be what was intended.
>
> Signed-off-by: Julia Lawall
Applied, thanks.
jon
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vge
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.
v12:
- Root memory cgroup is evaluated based on sum of the oom scores
of belonging tasks
- Do not fallback to the per-process behavior if there if
it wasn't possbile to kill a memcg victim
- Rebase on top of mm tree
v11:
- Fixed an
Document the cgroup-aware OOM killer.
Signed-off-by: Roman Gushchin
Acked-by: Johannes Weiner
Cc: Michal Hocko
Cc: Vladimir Davydov
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
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
On 19 October 2017 at 20:04, Ulf Hansson wrote:
> On 19 October 2017 at 19:21, Grygorii Strashko
> wrote:
>>
>>
>> On 10/19/2017 03:33 AM, Ulf Hansson wrote:
>>> On 18 October 2017 at 23:48, Rafael J. Wysocki wrote:
On Wednesday, October 18, 2017 9:45:11 PM CEST Grygorii Strashko wrote:
>>
On 19 October 2017 at 19:21, Grygorii Strashko wrote:
>
>
> On 10/19/2017 03:33 AM, Ulf Hansson wrote:
>> On 18 October 2017 at 23:48, Rafael J. Wysocki wrote:
>>> On Wednesday, October 18, 2017 9:45:11 PM CEST Grygorii Strashko wrote:
On 10/18/2017 09:11 AM, Ulf Hansson wrote:
>>>
>>>
[...]
>>> > Say you want to leave the parent suspended after system resume, but the
>>> > child drivers use pm_runtime_force_suspend|resume(). The parent would
>>> > then
>>> > need to use pm_runtime_force_suspend|resume() too, no?
>>>
>>> Actually no.
>>>
>>> Currently the other options of "def
On 10/19/2017 03:33 AM, Ulf Hansson wrote:
> On 18 October 2017 at 23:48, Rafael J. Wysocki wrote:
>> On Wednesday, October 18, 2017 9:45:11 PM CEST Grygorii Strashko wrote:
>>>
>>> On 10/18/2017 09:11 AM, Ulf Hansson wrote:
>>
>> [...]
>>
>> That's the point. We know pm_runtime_force_* work
2017-10-19 12:17 GMT+09:00 Cao jin :
> It does several fixes:
> 1. move the displaced ld example to its reasonale place.
> 2. add new example for command gzip.
> 3. fix 2 number errors.
> 4. fix format of chapter 7.x, make it looks the same as other chapters.
>
> Signed-off-by: Cao jin
> ---
Appl
On Thu, Oct 19, 2017 at 04:28:35PM +0100, Will Deacon wrote:
> On Thu, Oct 19, 2017 at 01:29:18PM +0100, Mark Rutland wrote:
> > Will, are you happy to queue this?
> >
> > There's a minor fixup [1] needed in patch 2, but otherwise this looks
> > good to me, and builds cleanly.
> >
> > I've pushed
On Thu, Oct 19, 2017 at 01:29:18PM +0100, Mark Rutland wrote:
> Will, are you happy to queue this?
>
> There's a minor fixup [1] needed in patch 2, but otherwise this looks
> good to me, and builds cleanly.
>
> I've pushed out a branch [2] with that fix folded in, in case that's
> easier for you.
On Wed 18-10-17 19:00:26, Du, Changbin wrote:
> Hi Hocko,
>
> On Tue, Oct 17, 2017 at 12:20:52PM +0200, Michal Hocko wrote:
> > [CC Kirill]
> >
> > On Mon 16-10-17 17:19:16, changbin...@intel.com wrote:
> > > From: Changbin Du
> > >
> > > This patch introduced 4 new interfaces to allocate a pre
Will, are you happy to queue this?
There's a minor fixup [1] needed in patch 2, but otherwise this looks
good to me, and builds cleanly.
I've pushed out a branch [2] with that fix folded in, in case that's
easier for you. Otherwise, feel free to pick these up with my Ack.
Thanks,
Mark.
[1]
htt
On 19 October 2017 at 00:12, Rafael J. Wysocki wrote:
> On Wednesday, October 18, 2017 4:11:33 PM CEST Ulf Hansson wrote:
>> [...]
>>
>> >>
>> >> The reason why pm_runtime_force_* needs to respects the hierarchy of
>> >> the RPM callbacks, is because otherwise it can't safely update the
>> >> runt
On Thu, 2017-10-19 at 13:35 +0200, SF Markus Elfring wrote:
> > > > > Omit an extra message for a memory allocation failure in this
> > > > > function.
> > > > >
> > > > > This issue was detected by using the Coccinelle software.
[]
> > > Do you see any need that I should extend subsequent commit
Omit an extra message for a memory allocation failure in this function.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
>>>
>>> Applied to modules-next, thanks.
>>
>> Thanks for your acceptance of this update suggestion after a bit o
On Thu, Oct 19, 2017 at 07:05:17PM +0800, Shaokun Zhang wrote:
> This patch adds support HiSilicon SoC uncore PMU driver framework and
> interfaces.
> +static bool hisi_validate_event_group(struct perf_event *event)
> +{
> + struct perf_event *sibling, *leader = event->group_leader;
> + st
>> This is a small allocation so it can't fail in current kernels. I can't
>> imagine a situation where this could fail and it wasn't dead easy to
>> debug. Most modules are loaded at boot so it's not likely to fail, but
>> if it did, it would be easy to reproduce. If it's not loaded at boot
>>
This patch adds support HiSilicon SoC uncore PMU driver framework and
interfaces.
Reviewed-by: Jonathan Cameron
Signed-off-by: Shaokun Zhang
Signed-off-by: Anurup M
---
drivers/perf/Kconfig | 7 +
drivers/perf/Makefile| 1 +
drivers/perf/hisilicon/Ma
This patch adds support for L3C PMU driver in HiSilicon SoC chip, Each
L3C has own control, counter and interrupt registers and is an separate
PMU. For each L3C PMU, it has 8-programable counters and each counter
is free-running. Interrupt is supported to handle counter (48-bits)
overflow.
Reviewe
Add support HiSilicon SoC uncore PMU driver.
Signed-off-by: Shaokun Zhang
---
MAINTAINERS | 7 +++
1 file changed, 7 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index a74227a..96c583c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6242,6 +6242,13 @@ S: Maintained
F: driv
This patch adds support for DDRC PMU driver in HiSilicon SoC chip, Each
DDRC has own control, counter and interrupt registers and is an separate
PMU. For each DDRC PMU, it has 8-fixed-purpose counters which have been
mapped to 8-events by hardware, it assumes that counter index is equal
to event co
L3 cache coherence is maintained by Hydra Home Agent (HHA) in HiSilicon
SoC. This patch adds support for HHA PMU driver, Each HHA has own
control, counter and interrupt registers and is an separate PMU. For
each HHA PMU, it has 16-programable counters and each counter is
free-running. Interrupt is
This patchset adds support for HiSilicon SoC uncore PMUs driver. It
includes L3C, Hydra Home Agent (HHA) and DDRC.
Changes in v6:
* remove redundant member hisi_pmu::oneline_cpus
* rename member hisi_pmu::id
* add event code check when event init
* fix online/offline notifier for L3C/HHA/DDRC
Cha
This patch adds documentation for the uncore PMUs on HiSilicon SoC.
Reviewed-by: Jonathan Cameron
Signed-off-by: Shaokun Zhang
Signed-off-by: Anurup M
---
Documentation/perf/hisi-pmu.txt | 53 +
1 file changed, 53 insertions(+)
create mode 100644 Docume
Add the document for the change of extended movable_node=nn[KMG]@ss[KMG].
Cc: Jonathan Corbet
Cc: linux-doc@vger.kernel.org
Signed-off-by: Chao Fan
---
Documentation/admin-guide/kernel-parameters.txt | 9 +
1 file changed, 9 insertions(+)
diff --git a/Documentation/admin-guide/kernel-p
On 18 October 2017 at 23:48, Rafael J. Wysocki wrote:
> On Wednesday, October 18, 2017 9:45:11 PM CEST Grygorii Strashko wrote:
>>
>> On 10/18/2017 09:11 AM, Ulf Hansson wrote:
>
> [...]
>
>> >>> That's the point. We know pm_runtime_force_* works nicely for the
>> >>> trivial middle-layer cases.
>
On Thu, Oct 19, 2017 at 01:17:31AM +0200, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
>
> The motivation for this change is to provide a way to work around
> a problem with the direct-complete mechanism used for avoiding
> system suspend/resume handling for devices in runtime suspend.
>
>
57 matches
Mail list logo
