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:
>
> Anyway,
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 spec
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 simil
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 creating pull
> > requ
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 request with miscellaneous
> >
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
>
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);
DECLA
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
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
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 belo
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
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
Cc: Vladimir Davydov
Cc: Joh
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
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..
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
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" escreveu:
>
>
The acpi_mask_gpe= kernel parameter documentation states that the range
of mask is 128 GPEs (0x00 to 0x7F). The acpi_masked_gpes mask is a u64 so
only 64 GPEs (0x00 to 0x3F) can really be masked.
Use a bitmap of size 0xFF instead of a u64 for the GPE mask so 256
GPEs can be masked.
Fixes: 9c4aa1
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 please summaris
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, I
19 matches
Mail list logo
