On Tue, 09 Jan 2018, Genki Sky wrote:
> I personally am happy with the more organized Documentation/ tree. But
> as everyone knows, there's still a bit of breakage. Not the most fun
> to fix. However, it seems some tools could help ease this process /
> prevent future breakage. I listed a couple b
This extends the sysfs interface for thermal cooling devices and exposes
some pretty useful statistics. These statistics have proven to be quite
useful specially while doing benchmarks related to the task scheduler,
where we want to make sure that nothing has disrupted the test,
specially the cooli
On Wed, 10 Jan 2018, Jonathan Corbet wrote:
> On Wed, 10 Jan 2018 15:04:53 +1100
> "Tobin C. Harding" wrote:
>
>> Posting as RFC in the hope that someone knows how to massage sphinx
>> correctly to fix this patch.
>>
>> Currently function kernel-doc contains a multi-line code snippet. This
>> is
On Thu, 11 Jan 2018, "Tobin C. Harding" wrote:
> On Wed, Jan 10, 2018 at 02:59:58PM -0700, Jonathan Corbet wrote:
>> ...rather than adding a separate "::" line, you can just
>> s/follows:/follows::/ and the Right Thing will happen (to the same extent
>> that it does now, anyway.
>
> Except that it
Hi Christoffer
On 2018/1/15 16:33, Christoffer Dall wrote:
> On Fri, Jan 12, 2018 at 06:05:23PM +, James Morse wrote:
>> On 15/12/17 03:30, gengdongjiu wrote:
>>> On 2017/12/7 14:37, gengdongjiu wrote:
>
> [...]
>
>>
>> (I recall someone saying migration is needed for any new KVM/cpu feature
Hi James,
thanks very much for your mail and reply, I will check it ASAP. Due to
recently busy with other thing, so reply may be late.
On 2018/1/13 2:05, James Morse wrote:
> Hi gengdongjiu,
>
> On 16/12/17 04:47, gengdongjiu wrote:
>> [...]
>>>
+ case ESR_ELx_AET_UER: /* The error
> Am 16.01.2018 um 11:22 schrieb Jani Nikula :
>
> On Wed, 10 Jan 2018, Jonathan Corbet wrote:
>> On Wed, 10 Jan 2018 15:04:53 +1100
>> "Tobin C. Harding" wrote:
>>
>>> Posting as RFC in the hope that someone knows how to massage sphinx
>>> correctly to fix this patch.
>>>
>>> Currently funct
On Tue, 16 Jan 2018, Markus Heiser wrote:
>> Am 16.01.2018 um 11:22 schrieb Jani Nikula :
>>
>> On Wed, 10 Jan 2018, Jonathan Corbet wrote:
>>> On Wed, 10 Jan 2018 15:04:53 +1100
>>> "Tobin C. Harding" wrote:
>>>
Posting as RFC in the hope that someone knows how to massage sphinx
cor
On Tue, Jan 16, 2018 at 07:33:03PM +0530, Naveen Panwar wrote:
> Hi Guys,
>
> I submitted a new patch with the suggestions from Al Viro, did you guys
> check it?
I do not see any patch from my in my queue :(
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a
On Wed, Jan 10, 2018 at 11:33:19PM +0100, Maciej S. Szmigiero wrote:
> Currently, cgroups v2 documentation contains only a generic remark that
> "How resource consumption in the root cgroup is governed is up to each
> controller", which isn't really telling users much, who need to dig in the
> code
On Fri 12 Jan 17:05 PST 2018, Karthikeyan Ramasubramanian wrote:
> Generic Interface (GENI) firmware based Qualcomm Universal Peripheral (QUP)
> Wrapper is a programmable module that is composed of multiple Serial
> Engines (SE) and can support various Serial Interfaces like UART, SPI,
> I2C, I3C,
On Mon, 15 Jan 2018, Johannes Weiner wrote:
> > It's quite trivial to allow the root mem cgroup to be compared exactly the
> > same as another cgroup. Please see
> > https://marc.info/?l=linux-kernel&m=151579459920305.
>
> This only says "that will be fixed" and doesn't address why I care.
>
On Mon, 15 Jan 2018, Michal Hocko wrote:
> > No, this isn't how kernel features get introduced. We don't design a new
> > kernel feature with its own API for a highly specialized usecase and then
> > claim we'll fix the problems later. Users will work around the
> > constraints of the new fea
On Tue 16-01-18 13:36:21, David Rientjes wrote:
> On Mon, 15 Jan 2018, Michal Hocko wrote:
>
> > > No, this isn't how kernel features get introduced. We don't design a new
> > > kernel feature with its own API for a highly specialized usecase and then
> > > claim we'll fix the problems later.
On Thu, Nov 16, 2017 at 5:23 AM, Greg Kroah-Hartman
wrote:
> Sometimes a single patch is the result of multiple authors. As git only
> can have one "author" of a patch, it is still good to properly give
> credit to the other developers of a commit. To address this, document
> the "Co-Developed-b
Hi Marcus,
On Sat, Jan 13, 2018 at 09:15:32PM +0100, Marcus Folkesson wrote:
> This driver let you plug in your RC controller to the adapter and
> use it as input device in various RC simulators.
>
> Signed-off-by: Marcus Folkesson
> ---
> v3:
> - Use RUDDER and MISC instead of TILT_X and
The behavior of killing an entire indivisible memory consumer, enabled
by memory.oom_group, is an oom policy itself. It specifies that all
usage should be accounted to an ancestor and, if selected by the cgroup
aware oom killer, all processes attached to it and its descendant mem
cgroups should be
There are three significant concerns about the cgroup aware oom killer as
it is implemented in -mm:
(1) allows users to evade the oom killer by creating subcontainers or
using other controllers since scoring is done per cgroup and not
hierarchically,
(2) does not allow the user to inf
One of the three significant concerns brought up about the cgroup aware
oom killer is that its decisionmaking is completely evaded by creating
subcontainers and attaching processes such that the ancestor's usage does
not exceed another cgroup on the system.
In this regard, users who do not distrib
The cgroup aware oom killer is needlessly declared for the entire system
by a mount option. It's unnecessary to force the system into a single
oom policy: either cgroup aware, or the traditional process aware.
This patch introduces a memory.oom_policy tunable for all mem cgroups.
It is currently
Now that each mem cgroup on the system has a memory.oom_policy tunable to
specify oom kill selection behavior, remove the needless "groupoom" mount
option that requires (1) the entire system to be forced, perhaps
unnecessarily, perhaps unexpectedly, into a single oom policy that
differs from the tr
From: Matthew Wilcox
At some stage of the conversion pipeline, something thought that the
DocBook entity # should be rendered as NUM instead of #.
Signed-off-by: Matthew Wilcox
---
Documentation/kernel-hacking/hacking.rst | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/
On Fri 12 Jan 17:05 PST 2018, Karthikeyan Ramasubramanian wrote:
> This driver manages the Generic Interface (GENI) firmware based Qualcomm
> Universal Peripheral (QUP) Wrapper. GENI based QUP is the next generation
> programmable module composed of multiple Serial Engines (SE) and supports
> a wi
On Fri 12 Jan 17:05 PST 2018, Karthikeyan Ramasubramanian wrote:
> Add device tree binding support for the QCOM GENI SE driver.
>
> Signed-off-by: Karthikeyan Ramasubramanian
Better describe the entire GENI, with it's functions in the same
binding.
> ---
> .../devicetree/bindings/soc/qcom/qco
On Fri 12 Jan 17:05 PST 2018, Karthikeyan Ramasubramanian wrote:
> Add device tree binding support for I2C Controller in GENI based
> QUP Wrapper.
>
> Signed-off-by: Sagar Dharia
> Signed-off-by: Karthikeyan Ramasubramanian
> ---
> .../devicetree/bindings/i2c/i2c-qcom-geni.txt | 35
> +++
On Fri 12 Jan 17:05 PST 2018, Karthikeyan Ramasubramanian wrote:
> Add device tree binding support for GENI based UART Controller in the
> QUP Wrapper.
>
> Signed-off-by: Karthikeyan Ramasubramanian
> Signed-off-by: Girish Mahadevan
> ---
> .../devicetree/bindings/serial/qcom,geni-uart.txt |
26 matches
Mail list logo
