* Re: [PATCH v2 2/2] perf: riscv: Add Document for Future Porting Guide
From: Alan Kao @ 2018-04-05 5:09 UTC (permalink / raw)
To: Alex Solomatnikov
Cc: Palmer Dabbelt, Albert Ou, Peter Zijlstra, Ingo Molnar,
Arnaldo Carvalho de Melo, Alexander Shishkin, Jiri Olsa,
Namhyung Kim, Jonathan Corbet, linux-riscv, linux-doc,
linux-kernel, Nick Hu, Greentime Hu
In-Reply-To: <CAJ2AOiM34QyHPZkpz3DEpkyWB2TJ-gK9qPM3rKc2dNDQXCRXiw@mail.gmail.com>
Hi Alex,
On Tue, Apr 03, 2018 at 07:08:43PM -0700, Alex Solomatnikov wrote:
> Doc fixes:
>
>
Thanks for these fixes. I'll edit this patch and send a v3 once I am done
with the PMU patch.
I suppose a "Reviewed-by: Alex Solomatnikov" appending at the end of the
commit will be great, right?
Alan
> diff --git a/Documentation/riscv/pmu.txt b/Documentation/riscv/pmu.txt
> index a3e930e..ae90a5e 100644
> --- a/Documentation/riscv/pmu.txt
> +++ b/Documentation/riscv/pmu.txt
> @@ -20,7 +20,7 @@ the lack of the following general architectural
> performance monitoring features:
> * Enabling/Disabling counters
> Counters are just free-running all the time in our case.
> * Interrupt caused by counter overflow
> - No such design in the spec.
> + No such feature in the spec.
> * Interrupt indicator
> It is not possible to have many interrupt ports for all counters, so an
> interrupt indicator is required for software to tell which counter has
> @@ -159,14 +159,14 @@ interrupt for perf, so the details are to be
> completed in the future.
>
> They seem symmetric but perf treats them quite differently. For reading, there
> is a *read* interface in *struct pmu*, but it serves more than just reading.
> -According to the context, the *read* function not only read the content of the
> -counter (event->count), but also update the left period to the next interrupt
> +According to the context, the *read* function not only reads the content of the
> +counter (event->count), but also updates the left period for the next interrupt
> (event->hw.period_left).
>
> But the core of perf does not need direct write to counters. Writing counters
> -hides behind the abstraction of 1) *pmu->start*, literally start
> counting so one
> +is hidden behind the abstraction of 1) *pmu->start*, literally start
> counting so one
> has to set the counter to a good value for the next interrupt; 2)
> inside the IRQ
> -it should set the counter with the same reason.
> +it should set the counter to the same reasonable value.
>
> Reading is not a problem in RISC-V but writing would need some effort, since
> counters are not allowed to be written by S-mode.
> @@ -190,37 +190,37 @@ Three states (event->hw.state) are defined:
> A normal flow of these state transitions are as follows:
>
> * A user launches a perf event, resulting in calling to *event_init*.
> -* When being context-switched in, *add* is called by the perf core, with flag
> - PERF_EF_START, which mean that the event should be started after it is added.
> - In this stage, an general event is binded to a physical counter, if any.
> +* When being context-switched in, *add* is called by the perf core, with a flag
> + PERF_EF_START, which means that the event should be started after
> it is added.
> + At this stage, a general event is bound to a physical counter, if any.
> The state changes to PERF_HES_STOPPED and PERF_HES_UPTODATE,
> because it is now
> stopped, and the (software) event count does not need updating.
> ** *start* is then called, and the counter is enabled.
> - With flag PERF_EF_RELOAD, it write the counter to an appropriate
> value (check
> - previous section for detail).
> - No writing is made if the flag does not contain PERF_EF_RELOAD.
> - The state now is reset to none, because it is neither stopped nor update
> - (the counting already starts)
> -* When being context-switched out, *del* is called. It then checkout all the
> - events in the PMU and call *stop* to update their counts.
> + With flag PERF_EF_RELOAD, it writes an appropriate value to the
> counter (check
> + the previous section for details).
> + Nothing is written if the flag does not contain PERF_EF_RELOAD.
> + The state now is reset to none, because it is neither stopped nor updated
> + (the counting already started)
> +* When being context-switched out, *del* is called. It then checks out all the
> + events in the PMU and calls *stop* to update their counts.
> ** *stop* is called by *del*
> and the perf core with flag PERF_EF_UPDATE, and it often shares the same
> subroutine as *read* with the same logic.
> The state changes to PERF_HES_STOPPED and PERF_HES_UPTODATE, again.
>
> -** Life cycles of these two pairs: *add* and *del* are called repeatedly as
> +** Life cycle of these two pairs: *add* and *del* are called repeatedly as
> tasks switch in-and-out; *start* and *stop* is also called when the perf core
> needs a quick stop-and-start, for instance, when the interrupt
> period is being
> adjusted.
>
> -Current implementation is sufficient for now and can be easily extend to
> +Current implementation is sufficient for now and can be easily
> extended with new
> features in the future.
>
> A. Related Structures
> ---------------------
>
> -* struct pmu: include/linux/perf_events.h
> -* struct riscv_pmu: arch/riscv/include/asm/perf_events.h
> +* struct pmu: include/linux/perf_event.h
> +* struct riscv_pmu: arch/riscv/include/asm/perf_event.h
>
> Both structures are designed to be read-only.
>
> @@ -231,13 +231,13 @@ perf's internal state machine (check
> kernel/events/core.c for details).
> *struct riscv_pmu* defines PMU-specific parameters. The naming follows the
> convention of all other architectures.
>
> -* struct perf_event: include/linux/perf_events.h
> +* struct perf_event: include/linux/perf_event.h
> * struct hw_perf_event
>
> The generic structure that represents perf events, and the hardware-related
> details.
>
> -* struct riscv_hw_events: arch/riscv/include/asm/perf_events.h
> +* struct riscv_hw_events: arch/riscv/include/asm/perf_event.h
>
> The structure that holds the status of events, has two fixed members:
> the number of events and the array of the events.
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RFC PATCH 0/3] Documentation/features: Provide and apply "features-refresh.sh"
From: Ingo Molnar @ 2018-04-05 15:18 UTC (permalink / raw)
To: Andrea Parri
Cc: Jonathan Corbet, linux-kernel, linux-doc, linux-arch,
Andrew Morton
In-Reply-To: <20180404130357.GA9125@andrea>
* Andrea Parri <andrea.parri@amarulasolutions.com> wrote:
> On Wed, Apr 04, 2018 at 06:56:32AM +0200, Ingo Molnar wrote:
> >
> > * Andrea Parri <andrea.parri@amarulasolutions.com> wrote:
> >
> > > In Ingo's words [1]:
> > >
> > > "[...] what should be done instead is to write a script that refreshes
> > > all the arch-support.txt files in-place. [...]
> > >
> > > It's OK for the script to have various quirks for weirdly implemented
> > > features and exceptions: i.e. basically whenever it gets a feature wrong,
> > > we can just tweak the script with quirks to make it all work out of box.
> > >
> > > [...] But in the end there should only be a single new script:
> > >
> > > Documentation/features/scripts/features-refresh.sh
> > >
> > > ... which operates on the arch-support.txt files and refreshes them in
> > > place, and which, after all the refreshes have been committed, should
> > > produce an empty 'git diff' result."
> > >
> > > "[...] New features can then be added by basically just creating a
> > > header-only arch-support.txt file, such as:
> > >
> > > triton:~/tip/Documentation/features> cat foo/bar/arch-support.txt
> > > #
> > > # Feature name: shiny new fubar kernel feature
> > > # Kconfig: ARCH_USE_FUBAR
> > > # description: arch supports the fubar feature
> > > #
> > >
> > > And running Documentation/features/scripts/features-refresh.sh would
> > > auto-generate the arch support matrix. [...]
> > >
> > > This way we soft- decouple the refreshing of the entries from the
> > > introduction of the features, while still making it all easy to keep
> > > sync and to extend."
> > >
> > > This RFC presents a first attempt to implement such a feature/script, and
> > > applies it script on top of Arnd's:
> > >
> > > git://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic.git arch-removal
> > >
> > > Patch 1/3 provides the "features-refresh.sh" script. Patch 2/3 removes the
> > > "BPF-JIT" feature file and it creates header-only files for "cBPF-JIT" and
> > > "eBPF-JIT". Patch 3/3 presents the results of running the script; this run
> > > also printed to standard output the following warnings:
> > >
> > > WARNING: '__HAVE_ARCH_STRNCASECMP' is not a valid Kconfig
> > > WARNING: 'Optimized asm/rwsem.h' is not a valid Kconfig
> > > WARNING: '!ARCH_USES_GETTIMEOFFSET' is not a valid Kconfig
> > > WARNING: '__HAVE_ARCH_PTE_SPECIAL' is not a valid Kconfig
> > >
> > > (I'm sending these patches with empty commit messagges, for early feedback:
> > > I'll fill in these messages in subsequent versions if this makes sense...)
> > >
> > > Cheers,
> > > Andrea
> > >
> > > Andrea Parri (3):
> > > Documentation/features: Add script that refreshes the arch support status files in place
> > > Documentation/features/core: Add arch support status files for 'cBPF-JIT' and 'eBPF-JIT'
> > > Documentation/features: Refresh and auto-generate the arch support status files in place
> >
> > Ok, this series is really impressive at its RFC stage already!
> >
> > Beyond fixing those warnings, I'd also suggest another change: please make the
> > new BPF features patch the last one, so that the 'refresh' patch shows how much
> > original bit-rot we gathered recently.
> >
> > The 'new features' patch should then also include the result of also running the
> > script, i.e. a single patch adding the base fields and the generated parts as
> > well. That will be the usual development flow anyway - people won't do two-part
> > patches just to show which bits are by hand and which are auto-generated.
>
> Yes, I'll do.
>
> Let me ask some hints about the warnings, as I'm not sure how to 'fix' them;
> we have:
>
> a) __HAVE_ARCH_STRNCASECMP
> __HAVE_ARCH_PTE_SPECIAL
>
> b) Optimized asm/rwsem.h
>
> c) !ARCH_USES_GETTIMEOFFSET
>
> For (c), I see two options:
>
> 1. replace that with 'ARCH_USES_GETTIMEOFFSET' (and update the status
> matrix accordingly)
>
> 2. add logics/code to the script to handle simple boolean expressions
> (mmh, this could get nasty really soon... let's say: limiting to a
> leading '!', to start with ;)
Yeah, so the problem here is that the feature is the _lack_ of legacy
ARCH_USES_GETTIMEOFFSET, so we cannot just invert the check - the output would be
rather confusing ...
Negating the switch in the kernel would force us to add a "arch uses modern
timekeeping" flag to every other architecture - not a very good solution.
I'd suggest adding support for a simple '!' operator with very strict syntax -
nothing more. (This would also be useful for (b), see below.)
> For (a), I realize that 'grep-ing' the macros in arch-specific _sources_
> does serve the purpose of producing the hard-coded status matrices; but
> is this a reasonable approach? (e.g., can produce 'false-positives'?)
I'd suggest removing both :-)
- strncasecmp() is an insignificant API and no arch has optimized it so far.
- __HAVE_ARCH_PTE_SPECIAL is really a hardware detail.
> What could it be a suitable solution for (b)? are there Kconfig options
> which I could in place of that expression? some other suggestion?
Yes, !RWSEM_GENERIC_SPINLOCK expresses this equivalently. If you implement the NOT
operator for ARCH_USES_GETTIMEOFFSET then it would handle this one as well.
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v3 5/7] thermal/drivers/cpu_cooling: Add idle cooling device documentation
From: Daniel Lezcano @ 2018-04-05 16:16 UTC (permalink / raw)
To: viresh.kumar, edubezval
Cc: kevin.wangtao, leo.yan, vincent.guittot, linux-kernel,
javi.merino, rui.zhang, daniel.thompson, linux-pm,
Jonathan Corbet, open list:DOCUMENTATION
In-Reply-To: <1522945005-7165-1-git-send-email-daniel.lezcano@linaro.org>
Provide some documentation for the idle injection cooling effect in
order to let people to understand the rational of the approach for the
idle injection CPU cooling device.
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
---
Documentation/thermal/cpu-idle-cooling.txt | 166 +++++++++++++++++++++++++++++
1 file changed, 166 insertions(+)
create mode 100644 Documentation/thermal/cpu-idle-cooling.txt
diff --git a/Documentation/thermal/cpu-idle-cooling.txt b/Documentation/thermal/cpu-idle-cooling.txt
new file mode 100644
index 0000000..457cd99
--- /dev/null
+++ b/Documentation/thermal/cpu-idle-cooling.txt
@@ -0,0 +1,166 @@
+
+Situation:
+----------
+
+Under certain circumstances a SoC can reach the maximum temperature
+limit or is unable to stabilize the temperature around a temperature
+control. When the SoC has to stabilize the temperature, the kernel can
+act on a cooling device to mitigate the dissipated power. When the
+maximum temperature is reached and to prevent a reboot or a shutdown,
+a decision must be taken to reduce the temperature under the critical
+threshold, that impacts the performance.
+
+Another situation is when the silicon reaches a certain temperature
+which continues to increase even if the dynamic leakage is reduced to
+its minimum by clock gating the component. The runaway phenomena will
+continue with the static leakage and only powering down the component,
+thus dropping the dynamic and static leakage will allow the component
+to cool down.
+
+Last but not least, the system can ask for a specific power budget but
+because of the OPP density, we can only choose an OPP with a power
+budget lower than the requested one and underuse the CPU, thus losing
+performances. In other words, one OPP under uses the CPU with a power
+lesser than the power budget and the next OPP exceed the power budget,
+an intermediate OPP could have been used if it were present.
+
+Solutions:
+----------
+
+If we can remove the static and the dynamic leakage for a specific
+duration in a controlled period, the SoC temperature will
+decrease. Acting at the idle state duration or the idle cycle
+injection period, we can mitigate the temperature by modulating the
+power budget.
+
+The Operating Performance Point (OPP) density has a great influence on
+the control precision of cpufreq, however different vendors have a
+plethora of OPP density, and some have large power gap between OPPs,
+that will result in loss of performance during thermal control and
+loss of power in other scenes.
+
+At a specific OPP, we can assume injecting idle cycle on all CPUs,
+belonging to the same cluster, with a duration greater than the
+cluster idle state target residency, we drop the static and the
+dynamic leakage for this period (modulo the energy needed to enter
+this state). So the sustainable power with idle cycles has a linear
+relation with the OPP’s sustainable power and can be computed with a
+coefficient similar to:
+
+ Power(IdleCycle) = Coef x Power(OPP)
+
+Idle Injection:
+---------------
+
+The base concept of the idle injection is to force the CPU to go to an
+idle state for a specified time each control cycle, it provides
+another way to control CPU power and heat in addition to
+cpufreq. Ideally, if all CPUs belonging to the same cluster, inject
+their idle cycle synchronously, the cluster can reach its power down
+state with a minimum power consumption and static leakage
+drop. However, these idle cycles injection will add extra latencies as
+the CPUs will have to wakeup from a deep sleep state.
+
+ ^
+ |
+ |
+ |------- ------- -------
+ |_______|_____|_______|_____|_______|___________
+
+ <----->
+ idle <---->
+ running
+
+With the fixed idle injection duration, we can give a value which is
+an acceptable performance drop off or latency when we reach a specific
+temperature and we begin to mitigate by varying the Idle injection
+period.
+
+The mitigation begins with a maximum period value which decrease when
+more cooling effect is requested. When the period duration is equal to
+the idle duration, then we are in a situation the platform can’t
+dissipate the heat enough and the mitigation fails. In this case the
+situation is considered critical and there is nothing to do. The idle
+injection duration must be changed by configuration and until we reach
+the cooling effect, otherwise an additionnal cooling device must be
+used or ultimately decrease the SoC performance by dropping the
+highest OPP point of the SoC.
+
+The idle injection duration value must comply with the constraints:
+
+- It is lesser or equal to the latency we tolerate when the mitigation
+ begins. It is platform dependent and will depend on the user
+ experience, reactivity vs performance trade off we want. This value
+ should be specified.
+
+- It is greater than the idle state’s target residency we want to go
+ for thermal mitigation, otherwise we end up consuming more energy.
+
+Minimum period
+--------------
+
+The idle injection duration being fixed, it is obvious the minimum
+period can’t be lesser than that, otherwise we will be scheduling the
+idle injection task right before the idle injection duration is
+complete, so waking up the CPU to put it asleep again.
+
+Maximum period
+--------------
+
+The maximum period is the initial period when the mitigation
+begins. Theoretically when we reach the thermal trip point, we have to
+sustain a specified power for specific temperature but at this time we
+consume:
+
+ Power = Capacitance x Voltage^2 x Frequency x Utilisation
+
+... which is more than the sustainable power (or there is something
+wrong on the system setup). The ‘Capacitance’ and ‘Utilisation’ are a
+fixed value, ‘Voltage’ and the ‘Frequency’ are fixed artificially
+because we don’t want to change the OPP. We can group the
+‘Capacitance’ and the ‘Utilisation’ into a single term which is the
+‘Dynamic Power Coefficient (Cdyn)’ Simplifying the above, we have:
+
+ Pdyn = Cdyn x Voltage^2 x Frequency
+
+The IPA will ask us somehow to reduce our power in order to target the
+sustainable power defined in the device tree. So with the idle
+injection mechanism, we want an average power (Ptarget) resulting on
+an amount of time running at full power on a specific OPP and idle
+another amount of time. That could be put in a equation:
+
+ P(opp)target = ((trunning x (P(opp)running) + (tidle P(opp)idle)) /
+ (trunning + tidle)
+ ...
+
+ tidle = trunning x ((P(opp)running / P(opp)target) - 1)
+
+At this point if we know the running period for the CPU, that gives us
+the idle injection, we need. Alternatively if we have the idle
+injection duration, we can compute the running duration with:
+
+ trunning = tidle / ((P(opp)running / P(opp)target) - 1)
+
+Practically, if the running power is lesses than the targeted power,
+we end up with a negative time value, so obviously the equation usage
+is bound to a power reduction, hence a higher OPP is needed to have
+the running power greater than the targeted power.
+
+However, in this demonstration we ignore three aspects:
+
+ * The static leakage is not defined here, we can introduce it in the
+ equation but assuming it will be zero most of the time as it is
+ difficult to get the values from the SoC vendors
+
+ * The idle state wake up latency (or entry + exit latency) is not
+ taken into account, it must be added in the equation in order to
+ rigorously compute the idle injection
+
+ * The injected idle duration must be greater than the idle state
+ target residency, otherwise we end up consuming more energy and
+ potentially invert the mitigation effect
+
+So the final equation is:
+
+ trunning = (tidle - twakeup ) x
+ (((P(opp)dyn + P(opp)static ) - P(opp)target) / P(opp)target )
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH 0/2] perf: riscv: Preliminary Perf Event Support on RISC-V
From: Palmer Dabbelt @ 2018-04-05 16:29 UTC (permalink / raw)
To: alankao
Cc: albert, peterz, mingo, acme, alexander.shishkin, jolsa, namhyung,
sols, corbet, linux-riscv, linux-doc, linux-kernel
In-Reply-To: <20180405050229.GA24451@andestech.com>
On Wed, 04 Apr 2018 22:02:29 PDT (-0700), alankao@andestech.com wrote:
> On Tue, Apr 03, 2018 at 03:45:17PM -0700, Palmer Dabbelt wrote:
>> On Tue, 03 Apr 2018 07:29:02 PDT (-0700), alankao@andestech.com wrote:
>> >On Mon, Apr 02, 2018 at 08:15:44PM -0700, Palmer Dabbelt wrote:
>> >>On Mon, 02 Apr 2018 05:31:22 PDT (-0700), alankao@andestech.com wrote:
>> >>>This implements the baseline PMU for RISC-V platforms.
>> >>>
>> >>>To ease future PMU portings, a guide is also written, containing
>> >>>perf concepts, arch porting practices and some hints.
>> >>>
>> >>>Changes in v2:
>> >>> - Fix the bug reported by Alex, which was caused by not sufficient
>> >>> initialization. Check https://lkml.org/lkml/2018/3/31/251 for the
>> >>> discussion.
>> >>>
>> >>>Alan Kao (2):
>> >>> perf: riscv: preliminary RISC-V support
>> >>> perf: riscv: Add Document for Future Porting Guide
>> >>>
>> >>> Documentation/riscv/pmu.txt | 249 +++++++++++++++++++
>> >>> arch/riscv/Kconfig | 12 +
>> >>> arch/riscv/include/asm/perf_event.h | 76 +++++-
>> >>> arch/riscv/kernel/Makefile | 1 +
>> >>> arch/riscv/kernel/perf_event.c | 468 ++++++++++++++++++++++++++++++++++++
>> >>> 5 files changed, 802 insertions(+), 4 deletions(-)
>> >>> create mode 100644 Documentation/riscv/pmu.txt
>> >>> create mode 100644 arch/riscv/kernel/perf_event.c
>> >>
>> >>I'm having some trouble pulling this into my tree. I think you might have
>> >>another patch floating around somewhere, as I don't have any
>> >>arch/riscv/include/asm/perf_event.h right now.
>> >>
>> >>Do you mind rebasing this on top of linux-4.16 so I can look properly?
>> >>
>> >>Thanks!
>> >
>> >Sorry for the inconvenience, but this patch was based on Alex's patch at
>> >https://github.com/riscv/riscv-linux/pull/124/files. I thought that one
>> >had already been picked into your tree.
>> >
>> >Any ideas?
>>
>> Thanks, it applies on top of that. I'm going to play around with this a
>> bit, but it looks generally good.
>
> Note that to make it work better when wraparound occurs, you should change the
> value of *.counter_width* into the width of real hardware counters. This is
> because this patch does not handle wraparound checking, so using a wider
> bit mask may sometimes report a extremely large number.
>
> Ideally this should be done by adding a Kconfig option called
> "Hifive Unleashed PMU" which automatically sets the width an reuses most of the
> baseline codes. What do you think about this?
We're working through this now :)
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/2] perf: riscv: preliminary RISC-V support
From: Palmer Dabbelt @ 2018-04-05 16:47 UTC (permalink / raw)
To: alankao
Cc: albert, peterz, mingo, acme, alexander.shishkin, jolsa, namhyung,
sols, corbet, linux-riscv, linux-doc, linux-kernel, alankao,
nickhu, greentime
In-Reply-To: <1522051075-6442-2-git-send-email-alankao@andestech.com>
On Mon, 26 Mar 2018 00:57:54 PDT (-0700), alankao@andestech.com wrote:
> This patch provide a basic PMU, riscv_base_pmu, which supports two
> general hardware event, instructions and cycles. Furthermore, this
> PMU serves as a reference implementation to ease the portings in
> the future.
>
> riscv_base_pmu should be able to run on any RISC-V machine that
> conforms to the Priv-Spec. Note that the latest qemu model hasn't
> fully support a proper behavior of Priv-Spec 1.10 yet, but work
> around should be easy with very small fixes. Please check
> https://github.com/riscv/riscv-qemu/pull/115 for future updates.
>
> Cc: Nick Hu <nickhu@andestech.com>
> Cc: Greentime Hu <greentime@andestech.com>
> Signed-off-by: Alan Kao <alankao@andestech.com>
We should really be able to detect PMU types at runtime (via a device tree
entry) rather than requiring that a single PMU is built in to the kernel. This
will require a handful of modifications to how this patch works, which I'll try
to list below.
> ---
> arch/riscv/Kconfig | 12 +
> arch/riscv/include/asm/perf_event.h | 76 +++++-
> arch/riscv/kernel/Makefile | 1 +
> arch/riscv/kernel/perf_event.c | 469 ++++++++++++++++++++++++++++++++++++
> 4 files changed, 554 insertions(+), 4 deletions(-)
> create mode 100644 arch/riscv/kernel/perf_event.c
>
> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> index 310b9a5d6737..dd4aecfb5265 100644
> --- a/arch/riscv/Kconfig
> +++ b/arch/riscv/Kconfig
> @@ -195,6 +195,18 @@ config RISCV_ISA_C
> config RISCV_ISA_A
> def_bool y
>
> +menu "PMU type"
> + depends on PERF_EVENTS
> +
> +config RISCV_BASE_PMU
> + bool "Base Performance Monitoring Unit"
> + def_bool y
> + help
> + A base PMU that serves as a reference implementation and has limited
> + feature of perf.
> +
> +endmenu
> +
> endmenu
Rather than a menu where a single PMU can be selected, there should be options
to enable or disable support for each PMU type -- this is just like how all our
other drivers work.
> menu "Kernel type"
> diff --git a/arch/riscv/include/asm/perf_event.h b/arch/riscv/include/asm/perf_event.h
> index e13d2ff29e83..98e2efb02d25 100644
> --- a/arch/riscv/include/asm/perf_event.h
> +++ b/arch/riscv/include/asm/perf_event.h
> @@ -1,13 +1,81 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> /*
> * Copyright (C) 2018 SiFive
> + * Copyright (C) 2018 Andes Technology Corporation
> *
> - * This program is free software; you can redistribute it and/or
> - * modify it under the terms of the GNU General Public Licence
> - * as published by the Free Software Foundation; either version
> - * 2 of the Licence, or (at your option) any later version.
> */
>
> #ifndef _ASM_RISCV_PERF_EVENT_H
> #define _ASM_RISCV_PERF_EVENT_H
>
> +#include <linux/perf_event.h>
> +#include <linux/ptrace.h>
> +
> +#define RISCV_BASE_COUNTERS 2
> +
> +/*
> + * The RISCV_MAX_COUNTERS parameter should be specified.
> + */
> +
> +#ifdef CONFIG_RISCV_BASE_PMU
> +#define RISCV_MAX_COUNTERS 2
> +#endif
> +
> +#ifndef RISCV_MAX_COUNTERS
> +#error "Please provide a valid RISCV_MAX_COUNTERS for the PMU."
> +#endif
> +
> +/*
> + * These are the indexes of bits in counteren register *minus* 1,
> + * except for cycle. It would be coherent if it can directly mapped
> + * to counteren bit definition, but there is a *time* register at
> + * counteren[1]. Per-cpu structure is scarce resource here.
> + *
> + * According to the spec, an implementation can support counter up to
> + * mhpmcounter31, but many high-end processors has at most 6 general
> + * PMCs, we give the definition to MHPMCOUNTER8 here.
> + */
> +#define RISCV_PMU_CYCLE 0
> +#define RISCV_PMU_INSTRET 1
> +#define RISCV_PMU_MHPMCOUNTER3 2
> +#define RISCV_PMU_MHPMCOUNTER4 3
> +#define RISCV_PMU_MHPMCOUNTER5 4
> +#define RISCV_PMU_MHPMCOUNTER6 5
> +#define RISCV_PMU_MHPMCOUNTER7 6
> +#define RISCV_PMU_MHPMCOUNTER8 7
> +
> +#define RISCV_OP_UNSUPP (-EOPNOTSUPP)
> +
> +struct cpu_hw_events {
> + /* # currently enabled events*/
> + int n_events;
> + /* currently enabled events */
> + struct perf_event *events[RISCV_MAX_COUNTERS];
> + /* vendor-defined PMU data */
> + void *platform;
> +};
> +
> +struct riscv_pmu {
> + struct pmu *pmu;
> +
> + /* generic hw/cache events table */
> + const int *hw_events;
> + const int (*cache_events)[PERF_COUNT_HW_CACHE_MAX]
> + [PERF_COUNT_HW_CACHE_OP_MAX]
> + [PERF_COUNT_HW_CACHE_RESULT_MAX];
> + /* method used to map hw/cache events */
> + int (*map_hw_event)(u64 config);
> + int (*map_cache_event)(u64 config);
> +
> + /* max generic hw events in map */
> + int max_events;
> + /* number total counters, 2(base) + x(general) */
> + int num_counters;
> + /* the width of the counter */
> + int counter_width;
> +
> + /* vendor-defined PMU features */
> + void *platform;
> +};
> +
> #endif /* _ASM_RISCV_PERF_EVENT_H */
> diff --git a/arch/riscv/kernel/Makefile b/arch/riscv/kernel/Makefile
> index 196f62ffc428..849c38d9105f 100644
> --- a/arch/riscv/kernel/Makefile
> +++ b/arch/riscv/kernel/Makefile
> @@ -36,5 +36,6 @@ obj-$(CONFIG_SMP) += smp.o
> obj-$(CONFIG_MODULES) += module.o
> obj-$(CONFIG_FUNCTION_TRACER) += mcount.o
> obj-$(CONFIG_FUNCTION_GRAPH_TRACER) += ftrace.o
> +obj-$(CONFIG_PERF_EVENTS) += perf_event.o
>
> clean:
> diff --git a/arch/riscv/kernel/perf_event.c b/arch/riscv/kernel/perf_event.c
> new file mode 100644
> index 000000000000..b78cb486683b
> --- /dev/null
> +++ b/arch/riscv/kernel/perf_event.c
> @@ -0,0 +1,469 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Copyright (C) 2008 Thomas Gleixner <tglx@linutronix.de>
> + * Copyright (C) 2008-2009 Red Hat, Inc., Ingo Molnar
> + * Copyright (C) 2009 Jaswinder Singh Rajput
> + * Copyright (C) 2009 Advanced Micro Devices, Inc., Robert Richter
> + * Copyright (C) 2008-2009 Red Hat, Inc., Peter Zijlstra
> + * Copyright (C) 2009 Intel Corporation, <markus.t.metzger@intel.com>
> + * Copyright (C) 2009 Google, Inc., Stephane Eranian
> + * Copyright 2014 Tilera Corporation. All Rights Reserved.
> + * Copyright (C) 2018 Andes Technology Corporation
> + *
> + * Perf_events support for RISC-V platforms.
> + *
> + * Since the spec. (as of now, Priv-Spec 1.10) does not provide enough
> + * functionality for perf event to fully work, this file provides
> + * the very basic framework only.
> + *
> + * For platform portings, please check Documentations/riscv/pmu.txt.
> + *
> + * The Copyright line includes x86 and tile ones.
> + */
> +
> +#include <linux/kprobes.h>
> +#include <linux/kernel.h>
> +#include <linux/kdebug.h>
> +#include <linux/mutex.h>
> +#include <linux/bitmap.h>
> +#include <linux/irq.h>
> +#include <linux/interrupt.h>
> +#include <linux/perf_event.h>
> +#include <linux/atomic.h>
> +#include <asm/perf_event.h>
> +
> +static const struct riscv_pmu *riscv_pmu __read_mostly;
> +static DEFINE_PER_CPU(struct cpu_hw_events, cpu_hw_events);
> +
> +/*
> + * Hardware & cache maps and their methods
> + */
> +
> +static const int riscv_hw_event_map[] = {
> + [PERF_COUNT_HW_CPU_CYCLES] = RISCV_PMU_CYCLE,
> + [PERF_COUNT_HW_INSTRUCTIONS] = RISCV_PMU_INSTRET,
> + [PERF_COUNT_HW_CACHE_REFERENCES] = RISCV_OP_UNSUPP,
> + [PERF_COUNT_HW_CACHE_MISSES] = RISCV_OP_UNSUPP,
> + [PERF_COUNT_HW_BRANCH_INSTRUCTIONS] = RISCV_OP_UNSUPP,
> + [PERF_COUNT_HW_BRANCH_MISSES] = RISCV_OP_UNSUPP,
> + [PERF_COUNT_HW_BUS_CYCLES] = RISCV_OP_UNSUPP,
> +};
> +
> +#define C(x) PERF_COUNT_HW_CACHE_##x
> +static const int riscv_cache_event_map[PERF_COUNT_HW_CACHE_MAX]
> +[PERF_COUNT_HW_CACHE_OP_MAX]
> +[PERF_COUNT_HW_CACHE_RESULT_MAX] = {
> + [C(L1D)] = {
> + [C(OP_READ)] = {
> + [C(RESULT_ACCESS)] = RISCV_OP_UNSUPP,
> + [C(RESULT_MISS)] = RISCV_OP_UNSUPP,
> + },
> + [C(OP_WRITE)] = {
> + [C(RESULT_ACCESS)] = RISCV_OP_UNSUPP,
> + [C(RESULT_MISS)] = RISCV_OP_UNSUPP,
> + },
> + [C(OP_PREFETCH)] = {
> + [C(RESULT_ACCESS)] = RISCV_OP_UNSUPP,
> + [C(RESULT_MISS)] = RISCV_OP_UNSUPP,
> + },
> + },
> + [C(L1I)] = {
> + [C(OP_READ)] = {
> + [C(RESULT_ACCESS)] = RISCV_OP_UNSUPP,
> + [C(RESULT_MISS)] = RISCV_OP_UNSUPP,
> + },
> + [C(OP_WRITE)] = {
> + [C(RESULT_ACCESS)] = RISCV_OP_UNSUPP,
> + [C(RESULT_MISS)] = RISCV_OP_UNSUPP,
> + },
> + [C(OP_PREFETCH)] = {
> + [C(RESULT_ACCESS)] = RISCV_OP_UNSUPP,
> + [C(RESULT_MISS)] = RISCV_OP_UNSUPP,
> + },
> + },
> + [C(LL)] = {
> + [C(OP_READ)] = {
> + [C(RESULT_ACCESS)] = RISCV_OP_UNSUPP,
> + [C(RESULT_MISS)] = RISCV_OP_UNSUPP,
> + },
> + [C(OP_WRITE)] = {
> + [C(RESULT_ACCESS)] = RISCV_OP_UNSUPP,
> + [C(RESULT_MISS)] = RISCV_OP_UNSUPP,
> + },
> + [C(OP_PREFETCH)] = {
> + [C(RESULT_ACCESS)] = RISCV_OP_UNSUPP,
> + [C(RESULT_MISS)] = RISCV_OP_UNSUPP,
> + },
> + },
> + [C(DTLB)] = {
> + [C(OP_READ)] = {
> + [C(RESULT_ACCESS)] = RISCV_OP_UNSUPP,
> + [C(RESULT_MISS)] = RISCV_OP_UNSUPP,
> + },
> + [C(OP_WRITE)] = {
> + [C(RESULT_ACCESS)] = RISCV_OP_UNSUPP,
> + [C(RESULT_MISS)] = RISCV_OP_UNSUPP,
> + },
> + [C(OP_PREFETCH)] = {
> + [C(RESULT_ACCESS)] = RISCV_OP_UNSUPP,
> + [C(RESULT_MISS)] = RISCV_OP_UNSUPP,
> + },
> + },
> + [C(ITLB)] = {
> + [C(OP_READ)] = {
> + [C(RESULT_ACCESS)] = RISCV_OP_UNSUPP,
> + [C(RESULT_MISS)] = RISCV_OP_UNSUPP,
> + },
> + [C(OP_WRITE)] = {
> + [C(RESULT_ACCESS)] = RISCV_OP_UNSUPP,
> + [C(RESULT_MISS)] = RISCV_OP_UNSUPP,
> + },
> + [C(OP_PREFETCH)] = {
> + [C(RESULT_ACCESS)] = RISCV_OP_UNSUPP,
> + [C(RESULT_MISS)] = RISCV_OP_UNSUPP,
> + },
> + },
> + [C(BPU)] = {
> + [C(OP_READ)] = {
> + [C(RESULT_ACCESS)] = RISCV_OP_UNSUPP,
> + [C(RESULT_MISS)] = RISCV_OP_UNSUPP,
> + },
> + [C(OP_WRITE)] = {
> + [C(RESULT_ACCESS)] = RISCV_OP_UNSUPP,
> + [C(RESULT_MISS)] = RISCV_OP_UNSUPP,
> + },
> + [C(OP_PREFETCH)] = {
> + [C(RESULT_ACCESS)] = RISCV_OP_UNSUPP,
> + [C(RESULT_MISS)] = RISCV_OP_UNSUPP,
> + },
> + },
> +};
> +
> +static int riscv_map_hw_event(u64 config)
> +{
> + if (config >= riscv_pmu->max_events)
> + return -EINVAL;
> +
> + return riscv_pmu->hw_events[config];
> +}
> +
> +int riscv_map_cache_decode(u64 config, unsigned int *type,
> + unsigned int *op, unsigned int *result)
> +{
> + return -ENOENT;
> +}
> +
> +static int riscv_map_cache_event(u64 config)
> +{
> + unsigned int type, op, result;
> + int err = -ENOENT;
> + int code;
> +
> + err = riscv_map_cache_decode(config, &type, &op, &result);
> + if (!riscv_pmu->cache_events || err)
> + return err;
> +
> + if (type >= PERF_COUNT_HW_CACHE_MAX ||
> + op >= PERF_COUNT_HW_CACHE_OP_MAX ||
> + result >= PERF_COUNT_HW_CACHE_RESULT_MAX)
> + return -EINVAL;
> +
> + code = (*riscv_pmu->cache_events)[type][op][result];
> + if (code == RISCV_OP_UNSUPP)
> + return -EINVAL;
> +
> + return code;
> +}
> +
> +/*
> + * Low-level functions: reading/writing counters
> + */
> +
> +static inline u64 read_counter(int idx)
> +{
> + u64 val = 0;
> +
> + switch (idx) {
> + case RISCV_PMU_CYCLE:
> + val = csr_read(cycle);
> + break;
> + case RISCV_PMU_INSTRET:
> + val = csr_read(instret);
> + break;
> + default:
> + WARN_ON_ONCE(idx < 0 || idx > RISCV_MAX_COUNTERS);
> + return -EINVAL;
> + }
> +
> + return val;
> +}
> +
> +static inline void write_counter(int idx, u64 value)
> +{
> + /* currently not supported */
> +}
> +
> +/*
> + * pmu->read: read and update the counter
> + *
> + * Other architectures' implementation often have a xxx_perf_event_update
> + * routine, which can return counter values when called in the IRQ, but
> + * return void when being called by the pmu->read method.
> + */
> +static void riscv_pmu_read(struct perf_event *event)
> +{
> + struct hw_perf_event *hwc = &event->hw;
> + u64 prev_raw_count, new_raw_count;
> + u64 oldval;
> + int idx = hwc->idx;
> + u64 delta;
> +
> + do {
> + prev_raw_count = local64_read(&hwc->prev_count);
> + new_raw_count = read_counter(idx);
> +
> + oldval = local64_cmpxchg(&hwc->prev_count, prev_raw_count,
> + new_raw_count);
> + } while (oldval != prev_raw_count);
> +
> + /*
> + * delta is the value to update the counter we maintain in the kernel.
> + */
> + delta = (new_raw_count - prev_raw_count) &
> + ((1ULL << riscv_pmu->counter_width) - 1);
> + local64_add(delta, &event->count);
> + /*
> + * Something like local64_sub(delta, &hwc->period_left) here is
> + * needed if there is an interrupt for perf.
> + */
> +}
> +
> +/*
> + * State transition functions:
> + *
> + * stop()/start() & add()/del()
> + */
> +
> +/*
> + * pmu->stop: stop the counter
> + */
> +static void riscv_pmu_stop(struct perf_event *event, int flags)
> +{
> + struct hw_perf_event *hwc = &event->hw;
> +
> + WARN_ON_ONCE(hwc->state & PERF_HES_STOPPED);
> + hwc->state |= PERF_HES_STOPPED;
> +
> + if ((flags & PERF_EF_UPDATE) && !(hwc->state & PERF_HES_UPTODATE)) {
> + riscv_pmu_read(event);
> + hwc->state |= PERF_HES_UPTODATE;
> + }
> +}
> +
> +/*
> + * pmu->start: start the event.
> + */
> +static void riscv_pmu_start(struct perf_event *event, int flags)
> +{
> + struct hw_perf_event *hwc = &event->hw;
> +
> + if (WARN_ON_ONCE(!(event->hw.state & PERF_HES_STOPPED)))
> + return;
> +
> + if (flags & PERF_EF_RELOAD) {
> + WARN_ON_ONCE(!(event->hw.state & PERF_HES_UPTODATE));
> +
> + /*
> + * Set the counter to the period to the next interrupt here,
> + * if you have any.
> + */
> + }
> +
> + hwc->state = 0;
> + perf_event_update_userpage(event);
> +
> + /*
> + * Since we cannot write to counters, this serves as an initialization
> + * to the delta-mechanism in pmu->read(); otherwise, the delta would be
> + * wrong when pmu->read is called for the first time.
> + */
> + if (local64_read(&hwc->prev_count) == 0)
> + local64_set(&hwc->prev_count, read_counter(hwc->idx));
> +}
> +
> +/*
> + * pmu->add: add the event to PMU.
> + */
> +static int riscv_pmu_add(struct perf_event *event, int flags)
> +{
> + struct cpu_hw_events *cpuc = this_cpu_ptr(&cpu_hw_events);
> + struct hw_perf_event *hwc = &event->hw;
> +
> + if (cpuc->n_events == riscv_pmu->num_counters)
> + return -ENOSPC;
> +
> + /*
> + * We don't have general conunters, so no binding-event-to-counter
> + * process here.
> + *
> + * Indexing using hwc->config generally not works, since config may
> + * contain extra information, but here the only info we have in
> + * hwc->config is the event index.
> + */
> + hwc->idx = hwc->config;
> + cpuc->events[hwc->idx] = event;
> + cpuc->n_events++;
> +
> + hwc->state = PERF_HES_UPTODATE | PERF_HES_STOPPED;
> +
> + if (flags & PERF_EF_START)
> + riscv_pmu_start(event, PERF_EF_RELOAD);
> +
> + return 0;
> +}
> +
> +/*
> + * pmu->del: delete the event from PMU.
> + */
> +static void riscv_pmu_del(struct perf_event *event, int flags)
> +{
> + struct cpu_hw_events *cpuc = this_cpu_ptr(&cpu_hw_events);
> + struct hw_perf_event *hwc = &event->hw;
> +
> + cpuc->events[hwc->idx] = NULL;
> + cpuc->n_events--;
> + riscv_pmu_stop(event, PERF_EF_UPDATE);
> + perf_event_update_userpage(event);
> +}
> +
> +/*
> + * Interrupt
> + */
> +
> +static DEFINE_MUTEX(pmc_reserve_mutex);
> +typedef void (*perf_irq_t)(void *riscv_perf_irq);
> +perf_irq_t perf_irq;
> +
> +void riscv_pmu_handle_irq(void *riscv_perf_irq)
> +{
> +}
> +
> +static perf_irq_t reserve_pmc_hardware(void)
> +{
> + perf_irq_t old;
> +
> + mutex_lock(&pmc_reserve_mutex);
> + old = perf_irq;
> + perf_irq = &riscv_pmu_handle_irq;
> + mutex_unlock(&pmc_reserve_mutex);
> +
> + return old;
> +}
> +
> +void release_pmc_hardware(void)
> +{
> + mutex_lock(&pmc_reserve_mutex);
> + perf_irq = NULL;
> + mutex_unlock(&pmc_reserve_mutex);
> +}
> +
> +/*
> + * Event Initialization
> + */
> +
> +static atomic_t riscv_active_events;
> +
> +static void riscv_event_destroy(struct perf_event *event)
> +{
> + if (atomic_dec_return(&riscv_active_events) == 0)
> + release_pmc_hardware();
> +}
> +
> +static int riscv_event_init(struct perf_event *event)
> +{
> + struct perf_event_attr *attr = &event->attr;
> + struct hw_perf_event *hwc = &event->hw;
> + perf_irq_t old_irq_handler = NULL;
> + int code;
> +
> + if (atomic_inc_return(&riscv_active_events) == 1)
> + old_irq_handler = reserve_pmc_hardware();
> +
> + if (old_irq_handler) {
> + pr_warn("PMC hardware busy (reserved by oprofile)\n");
> + atomic_dec(&riscv_active_events);
> + return -EBUSY;
> + }
> +
> + switch (event->attr.type) {
> + case PERF_TYPE_HARDWARE:
> + code = riscv_pmu->map_hw_event(attr->config);
> + break;
> + case PERF_TYPE_HW_CACHE:
> + code = riscv_pmu->map_cache_event(attr->config);
> + break;
> + case PERF_TYPE_RAW:
> + return -EOPNOTSUPP;
> + default:
> + return -ENOENT;
> + }
> +
> + event->destroy = riscv_event_destroy;
> + if (code < 0) {
> + event->destroy(event);
> + return code;
> + }
> +
> + /*
> + * idx is set to -1 because the index of a general event should not be
> + * decided until binding to some counter in pmu->add().
> + *
> + * But since we don't have such support, later in pmu->add(), we just
> + * use hwc->config as the index instead.
> + */
> + hwc->config = code;
> + hwc->idx = -1;
> +
> + return 0;
> +}
> +
> +/*
> + * Initialization
> + */
> +
> +static struct pmu min_pmu = {
> + .name = "riscv-base",
> + .event_init = riscv_event_init,
> + .add = riscv_pmu_add,
> + .del = riscv_pmu_del,
> + .start = riscv_pmu_start,
> + .stop = riscv_pmu_stop,
> + .read = riscv_pmu_read,
> +};
> +
> +static const struct riscv_pmu riscv_base_pmu = {
> + .pmu = &min_pmu,
> + .max_events = ARRAY_SIZE(riscv_hw_event_map),
> + .map_hw_event = riscv_map_hw_event,
> + .hw_events = riscv_hw_event_map,
> + .map_cache_event = riscv_map_cache_event,
> + .cache_events = &riscv_cache_event_map,
> + .counter_width = 63,
> + .num_counters = RISCV_BASE_COUNTERS + 0,
> +};
> +
> +struct pmu * __weak __init riscv_init_platform_pmu(void)
> +{
> + riscv_pmu = &riscv_base_pmu;
> + return riscv_pmu->pmu;
> +}
Rather than relying on a weak symbol that gets overridden by other PMU types,
this should look through the device tree for a compatible PMU (in the case of
just the base PMU it could be any RISC-V hart) and install a PMU handler for
it. There'd probably be some sort of priority scheme here, like there are for
other driver subsystems, where we'd pick the best PMU driver that's compatible
with the PMUs on every hart.
> +
> +int __init init_hw_perf_events(void)
> +{
> + struct pmu *pmu = riscv_init_platform_pmu();
> +
> + perf_irq = NULL;
> + perf_pmu_register(pmu, "cpu", PERF_TYPE_RAW);
> + return 0;
> +}
> +arch_initcall(init_hw_perf_events);
Since we only have a single PMU type right now this isn't critical to handle
right away, but we will have to refactor this before adding another PMU.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v3 4/4] mm/docs: describe memory.low refinements
From: Roman Gushchin @ 2018-04-05 18:59 UTC (permalink / raw)
To: linux-mm
Cc: Roman Gushchin, Andrew Morton, Johannes Weiner, Michal Hocko,
Vladimir Davydov, Tejun Heo, kernel-team, cgroups, linux-kernel,
linux-doc
In-Reply-To: <20180405185921.4942-1-guro@fb.com>
Refine cgroup v2 docs after latest memory.low changes.
Signed-off-by: Roman Gushchin <guro@fb.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: Vladimir Davydov <vdavydov.dev@gmail.com>
Cc: Tejun Heo <tj@kernel.org>
Cc: kernel-team@fb.com
Cc: linux-mm@kvack.org
Cc: cgroups@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-doc@vger.kernel.org
---
Documentation/cgroup-v2.txt | 28 +++++++++++++---------------
1 file changed, 13 insertions(+), 15 deletions(-)
diff --git a/Documentation/cgroup-v2.txt b/Documentation/cgroup-v2.txt
index f728e55602b2..7ee462b8a6ac 100644
--- a/Documentation/cgroup-v2.txt
+++ b/Documentation/cgroup-v2.txt
@@ -1006,10 +1006,17 @@ PAGE_SIZE multiple when read back.
A read-write single value file which exists on non-root
cgroups. The default is "0".
- Best-effort memory protection. If the memory usages of a
- cgroup and all its ancestors are below their low boundaries,
- the cgroup's memory won't be reclaimed unless memory can be
- reclaimed from unprotected cgroups.
+ Best-effort memory protection. If the memory usage of a
+ cgroup is within its effective low boundary, the cgroup's
+ memory won't be reclaimed unless memory can be reclaimed
+ from unprotected cgroups.
+
+ Effective low boundary is limited by memory.low values of
+ all ancestor cgroups. If there is memory.low overcommitment
+ (child cgroup or cgroups are requiring more protected memory,
+ than parent will allow), then each child cgroup will get
+ the part of parent's protection proportional to the its
+ actual memory usage below memory.low.
Putting more memory than generally available under this
protection is discouraged.
@@ -2008,17 +2015,8 @@ system performance due to overreclaim, to the point where the feature
becomes self-defeating.
The memory.low boundary on the other hand is a top-down allocated
-reserve. A cgroup enjoys reclaim protection when it and all its
-ancestors are below their low boundaries, which makes delegation of
-subtrees possible. Secondly, new cgroups have no reserve per default
-and in the common case most cgroups are eligible for the preferred
-reclaim pass. This allows the new low boundary to be efficiently
-implemented with just a minor addition to the generic reclaim code,
-without the need for out-of-band data structures and reclaim passes.
-Because the generic reclaim code considers all cgroups except for the
-ones running low in the preferred first reclaim pass, overreclaim of
-individual groups is eliminated as well, resulting in much better
-overall workload performance.
+reserve. A cgroup enjoys reclaim protection when it's within its low,
+which makes delegation of subtrees possible.
The original high boundary, the hard limit, is defined as a strict
limit that can not budge, even if the OOM killer has to be called.
--
2.14.3
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH v6 0/5] Introduce GENI SE Controller Driver
From: Karthik Ramasubramanian @ 2018-04-05 19:05 UTC (permalink / raw)
To: corbet, andy.gross, david.brown, robh+dt, mark.rutland, wsa
Cc: linux-doc, linux-arm-msm, devicetree, linux-i2c, evgreen,
acourbot, swboyd, dianders, bjorn.andersson
In-Reply-To: <1522429700-13083-1-git-send-email-kramasub@codeaurora.org>
Hi Maintainers,
Sorry if I am stepping in too soon. Since all the patches in this series
have been reviewed and remaining silent for some time, would you please
mind pulling in these patches as part of your next pull request.
Thanks and Regards,
Karthik.
On 3/30/2018 11:08 AM, Karthikeyan Ramasubramanian wrote:
> Generic Interface (GENI) firmware based Qualcomm Universal Peripheral (QUP)
> Wrapper is a next generation programmable module for supporting a wide
> range of serial interfaces like UART, SPI, I2C, I3C, etc. A single QUP
> module can provide upto 8 Serial Interfaces using its internal Serial
> Engines (SE). The protocol supported by each interface is determined by
> the firmware loaded to the Serial Engine.
>
> This patch series introduces GENI SE Driver to manage the GENI based QUP
> Wrapper and the common aspects of all SEs inside the QUP Wrapper. This
> patch series also introduces the UART and I2C Controller drivers to
> drive the SEs that are programmed with the respective protocols.
>
> [v6]
> * Move the I2C clock-frequency configuration to the SDM845 board file
> * Remove a redundant comment in the I2C driver
>
> [v5]
> * Remove Linux specific property from the device tree binding
> * Clarify I2C SCL time period documentation
> * Remove redundant checks in I2C controller driver during timeout
> * Use 100kHz as the default clock frequency in the I2C controller driver
> * Disable Wrapper controller by default in the SDM845 device tree and
> enable it explicitly for SDM845 MTP
> * Specify I2C clock frequency in the SDM845 device tree
> * Remove bias configuration for I2C pins under sleep state in device tree
> * Drop the serial driver from the patch series since it is merged
> * Specify the UART port options in the SDM845 device tree
>
> [v4]
> * Add SPI controller information in device tree binding
> * Add support for debug UART & I2C controllers in SDM845 device tree
> * Remove any unnecessary parenthesis & casting
> * Identify break character in UART line and pass it to the framework
> * Transmit data from fault handler reliably in debug UART
> * Map the register block when the UART port is requested
> * Move concise exported functions as macros or inlines in public header
> * Move the clock performance table from the wrapper to serial engines
> * Add a lock to synchronize between IRQ & error handling in I2C controller
> * Remove any compiler optimization hints like likely/unlikely
> * Update documentation to clarify tables and hardware blocks
>
> [v3]
> * Update the driver dependencies
> * Use the SPDX License Expression
> * Squash all the controller device tree bindings together
> * Use kernel doc format for documentation
> * Add additional documentation for packing configuration
> * Use clk_bulk_* API for related clocks
> * Remove driver references to pinctrl and their states
> * Replace magic numbers with appropriate macros
> * Update memory barrier usage and associated comments
> * Reduce interlacing of register reads/writes
> * Fix poll_get_char() operation in console UART driver under polling mode
> * Address other comments from Bjorn Andersson to improve code readability
>
> [v2]
> * Updated device tree bindings to describe the hardware
> * Updated SE DT node as child node of QUP Wrapper DT node
> * Moved common AHB clocks to QUP Wrapper DT node
> * Use the standard "clock-frequency" I2C property
> * Update compatible field in UART Controller to reflect hardware manual
> * Addressed other device tree binding specific comments from Rob Herring
>
> Karthikeyan Ramasubramanian (4):
> dt-bindings: soc: qcom: Add device tree binding for GENI SE
> soc: qcom: Add GENI based QUP Wrapper driver
> i2c: i2c-qcom-geni: Add bus driver for the Qualcomm GENI I2C
> controller
> arm64: dts: sdm845: Add support for an instance of I2C controller
>
> Rajendra Nayak (1):
> arm64: dts: sdm845: Add serial console support
>
> .../devicetree/bindings/soc/qcom/qcom,geni-se.txt | 119 ++++
> arch/arm64/boot/dts/qcom/sdm845-mtp.dts | 60 ++
> arch/arm64/boot/dts/qcom/sdm845.dtsi | 67 ++
> drivers/i2c/busses/Kconfig | 13 +
> drivers/i2c/busses/Makefile | 1 +
> drivers/i2c/busses/i2c-qcom-geni.c | 649 ++++++++++++++++++
> drivers/soc/qcom/Kconfig | 9 +
> drivers/soc/qcom/Makefile | 1 +
> drivers/soc/qcom/qcom-geni-se.c | 748 +++++++++++++++++++++
> include/linux/qcom-geni-se.h | 425 ++++++++++++
> 10 files changed, 2092 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.txt
> create mode 100644 drivers/i2c/busses/i2c-qcom-geni.c
> create mode 100644 drivers/soc/qcom/qcom-geni-se.c
> create mode 100644 include/linux/qcom-geni-se.h
>
--
Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 4/4] mm/docs: describe memory.low refinements
From: Johannes Weiner @ 2018-04-05 19:46 UTC (permalink / raw)
To: Roman Gushchin
Cc: linux-mm, Andrew Morton, Michal Hocko, Vladimir Davydov,
Tejun Heo, kernel-team, cgroups, linux-kernel, linux-doc
In-Reply-To: <20180405185921.4942-4-guro@fb.com>
On Thu, Apr 05, 2018 at 07:59:21PM +0100, Roman Gushchin wrote:
> Refine cgroup v2 docs after latest memory.low changes.
>
> Signed-off-by: Roman Gushchin <guro@fb.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Johannes Weiner <hannes@cmpxchg.org>
> Cc: Michal Hocko <mhocko@kernel.org>
> Cc: Vladimir Davydov <vdavydov.dev@gmail.com>
> Cc: Tejun Heo <tj@kernel.org>
> Cc: kernel-team@fb.com
> Cc: linux-mm@kvack.org
> Cc: cgroups@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-doc@vger.kernel.org
Acked-by: Johannes Weiner <hannes@cmpxchg.org>
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* make xmldocs failed with error after 4.17 merge period
From: Masanari Iida @ 2018-04-06 3:38 UTC (permalink / raw)
To: linux-kernel, linux-doc, Jonathan Corbet, heikki.krogerus,
Greg KH, linux-usb
After merge following patch during 4.17 merger period,
make xmldocs start to fail with error.
[bdecb33af34f79cbfbb656661210f77c8b8b5b5f]
usb: typec: API for controlling USB Type-C Multiplexers
Error messages.
reST markup error:
/home/iida/Repo/linux-2.6/Documentation/driver-api/usb/typec.rst:215:
(SEVERE/4) Unexpected section title or transition.
------------------------
Documentation/Makefile:93: recipe for target 'xmldocs' failed
make[1]: *** [xmldocs] Error 1
Makefile:1527: recipe for target 'xmldocs' failed
make: *** [xmldocs] Error 2
$
An ascii graphic in typec.rst cause the error.
Masanari Iida
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: make xmldocs failed with error after 4.17 merge period
From: Heikki Krogerus @ 2018-04-06 7:51 UTC (permalink / raw)
To: Masanari Iida
Cc: linux-kernel, linux-doc, Jonathan Corbet, Greg KH, linux-usb
In-Reply-To: <CALLJCT0MFg6b+dG50cqe_hv6hxmQDj-ZM066BOtQt_wOiC8ENA@mail.gmail.com>
On Fri, Apr 06, 2018 at 12:38:42PM +0900, Masanari Iida wrote:
> After merge following patch during 4.17 merger period,
> make xmldocs start to fail with error.
>
> [bdecb33af34f79cbfbb656661210f77c8b8b5b5f]
> usb: typec: API for controlling USB Type-C Multiplexers
>
> Error messages.
> reST markup error:
> /home/iida/Repo/linux-2.6/Documentation/driver-api/usb/typec.rst:215:
> (SEVERE/4) Unexpected section title or transition.
>
> ------------------------
> Documentation/Makefile:93: recipe for target 'xmldocs' failed
> make[1]: *** [xmldocs] Error 1
> Makefile:1527: recipe for target 'xmldocs' failed
> make: *** [xmldocs] Error 2
>
> $
>
> An ascii graphic in typec.rst cause the error.
Thanks for the report. I'm going to propose that we fix this by
marking the ascii art as comment:
diff --git a/Documentation/driver-api/usb/typec.rst b/Documentation/driver-api/usb/typec.rst
index feb31946490b..972c11bf4141 100644
--- a/Documentation/driver-api/usb/typec.rst
+++ b/Documentation/driver-api/usb/typec.rst
@@ -212,7 +212,7 @@ port drivers can use USB Role Class API with those.
Illustration of the muxes behind a connector that supports an alternate mode:
- ------------------------
+.. ------------------------
| Connector |
------------------------
| |
I hope that works.
Br,
--
heikki
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: make xmldocs failed with error after 4.17 merge period
From: Greg KH @ 2018-04-06 7:57 UTC (permalink / raw)
To: Heikki Krogerus
Cc: Masanari Iida, linux-kernel, linux-doc, Jonathan Corbet,
linux-usb
In-Reply-To: <20180406075109.GA21589@kuha.fi.intel.com>
On Fri, Apr 06, 2018 at 10:51:09AM +0300, Heikki Krogerus wrote:
> On Fri, Apr 06, 2018 at 12:38:42PM +0900, Masanari Iida wrote:
> > After merge following patch during 4.17 merger period,
> > make xmldocs start to fail with error.
> >
> > [bdecb33af34f79cbfbb656661210f77c8b8b5b5f]
> > usb: typec: API for controlling USB Type-C Multiplexers
> >
> > Error messages.
> > reST markup error:
> > /home/iida/Repo/linux-2.6/Documentation/driver-api/usb/typec.rst:215:
> > (SEVERE/4) Unexpected section title or transition.
> >
> > ------------------------
> > Documentation/Makefile:93: recipe for target 'xmldocs' failed
> > make[1]: *** [xmldocs] Error 1
> > Makefile:1527: recipe for target 'xmldocs' failed
> > make: *** [xmldocs] Error 2
> >
> > $
> >
> > An ascii graphic in typec.rst cause the error.
>
> Thanks for the report. I'm going to propose that we fix this by
> marking the ascii art as comment:
>
> diff --git a/Documentation/driver-api/usb/typec.rst b/Documentation/driver-api/usb/typec.rst
> index feb31946490b..972c11bf4141 100644
> --- a/Documentation/driver-api/usb/typec.rst
> +++ b/Documentation/driver-api/usb/typec.rst
> @@ -212,7 +212,7 @@ port drivers can use USB Role Class API with those.
>
> Illustration of the muxes behind a connector that supports an alternate mode:
>
> - ------------------------
> +.. ------------------------
> | Connector |
> ------------------------
> | |
>
> I hope that works.
Try it and see! :)
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: make xmldocs failed with error after 4.17 merge period
From: Heikki Krogerus @ 2018-04-06 8:15 UTC (permalink / raw)
To: Greg KH; +Cc: Masanari Iida, linux-kernel, linux-doc, Jonathan Corbet,
linux-usb
In-Reply-To: <20180406075734.GA16728@kroah.com>
On Fri, Apr 06, 2018 at 09:57:34AM +0200, Greg KH wrote:
> On Fri, Apr 06, 2018 at 10:51:09AM +0300, Heikki Krogerus wrote:
> > On Fri, Apr 06, 2018 at 12:38:42PM +0900, Masanari Iida wrote:
> > > After merge following patch during 4.17 merger period,
> > > make xmldocs start to fail with error.
> > >
> > > [bdecb33af34f79cbfbb656661210f77c8b8b5b5f]
> > > usb: typec: API for controlling USB Type-C Multiplexers
> > >
> > > Error messages.
> > > reST markup error:
> > > /home/iida/Repo/linux-2.6/Documentation/driver-api/usb/typec.rst:215:
> > > (SEVERE/4) Unexpected section title or transition.
> > >
> > > ------------------------
> > > Documentation/Makefile:93: recipe for target 'xmldocs' failed
> > > make[1]: *** [xmldocs] Error 1
> > > Makefile:1527: recipe for target 'xmldocs' failed
> > > make: *** [xmldocs] Error 2
> > >
> > > $
> > >
> > > An ascii graphic in typec.rst cause the error.
> >
> > Thanks for the report. I'm going to propose that we fix this by
> > marking the ascii art as comment:
> >
> > diff --git a/Documentation/driver-api/usb/typec.rst b/Documentation/driver-api/usb/typec.rst
> > index feb31946490b..972c11bf4141 100644
> > --- a/Documentation/driver-api/usb/typec.rst
> > +++ b/Documentation/driver-api/usb/typec.rst
> > @@ -212,7 +212,7 @@ port drivers can use USB Role Class API with those.
> >
> > Illustration of the muxes behind a connector that supports an alternate mode:
> >
> > - ------------------------
> > +.. ------------------------
> > | Connector |
> > ------------------------
> > | |
> >
> > I hope that works.
>
> Try it and see! :)
It will fix this issue. I was just wondering if use of ascii art is
acceptable in general with the .rst files? But then again, why
wouldn't it be.
Sorry for the noise. I'll just send that patch.
Thanks,
--
heikki
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] Documentation: typec.rst: Mark ascii art as a comment
From: Heikki Krogerus @ 2018-04-06 8:22 UTC (permalink / raw)
To: Greg KH, Jonathan Corbet
Cc: Masanari Iida, linux-kernel, linux-doc, linux-usb
To prevent processing of ascii art as reStructuredText
elements, marking it as a comment.
Reported-by: Masanari Iida <standby24x7@gmail.com>
Fixes: bdecb33af34f ("usb: typec: API for controlling USB Type-C Multiplexers")
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
---
Documentation/driver-api/usb/typec.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/driver-api/usb/typec.rst b/Documentation/driver-api/usb/typec.rst
index feb31946490b..972c11bf4141 100644
--- a/Documentation/driver-api/usb/typec.rst
+++ b/Documentation/driver-api/usb/typec.rst
@@ -212,7 +212,7 @@ port drivers can use USB Role Class API with those.
Illustration of the muxes behind a connector that supports an alternate mode:
- ------------------------
+.. ------------------------
| Connector |
------------------------
| |
--
2.16.3
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: make xmldocs failed with error after 4.17 merge period
From: Greg KH @ 2018-04-06 8:30 UTC (permalink / raw)
To: Heikki Krogerus
Cc: Masanari Iida, linux-kernel, linux-doc, Jonathan Corbet,
linux-usb
In-Reply-To: <20180406081555.GB21589@kuha.fi.intel.com>
On Fri, Apr 06, 2018 at 11:15:55AM +0300, Heikki Krogerus wrote:
> On Fri, Apr 06, 2018 at 09:57:34AM +0200, Greg KH wrote:
> > On Fri, Apr 06, 2018 at 10:51:09AM +0300, Heikki Krogerus wrote:
> > > On Fri, Apr 06, 2018 at 12:38:42PM +0900, Masanari Iida wrote:
> > > > After merge following patch during 4.17 merger period,
> > > > make xmldocs start to fail with error.
> > > >
> > > > [bdecb33af34f79cbfbb656661210f77c8b8b5b5f]
> > > > usb: typec: API for controlling USB Type-C Multiplexers
> > > >
> > > > Error messages.
> > > > reST markup error:
> > > > /home/iida/Repo/linux-2.6/Documentation/driver-api/usb/typec.rst:215:
> > > > (SEVERE/4) Unexpected section title or transition.
> > > >
> > > > ------------------------
> > > > Documentation/Makefile:93: recipe for target 'xmldocs' failed
> > > > make[1]: *** [xmldocs] Error 1
> > > > Makefile:1527: recipe for target 'xmldocs' failed
> > > > make: *** [xmldocs] Error 2
> > > >
> > > > $
> > > >
> > > > An ascii graphic in typec.rst cause the error.
> > >
> > > Thanks for the report. I'm going to propose that we fix this by
> > > marking the ascii art as comment:
> > >
> > > diff --git a/Documentation/driver-api/usb/typec.rst b/Documentation/driver-api/usb/typec.rst
> > > index feb31946490b..972c11bf4141 100644
> > > --- a/Documentation/driver-api/usb/typec.rst
> > > +++ b/Documentation/driver-api/usb/typec.rst
> > > @@ -212,7 +212,7 @@ port drivers can use USB Role Class API with those.
> > >
> > > Illustration of the muxes behind a connector that supports an alternate mode:
> > >
> > > - ------------------------
> > > +.. ------------------------
> > > | Connector |
> > > ------------------------
> > > | |
> > >
> > > I hope that works.
> >
> > Try it and see! :)
>
> It will fix this issue. I was just wondering if use of ascii art is
> acceptable in general with the .rst files? But then again, why
> wouldn't it be.
There are ways to do this, look at how the v4l2 and I think the drm
subsystems handle ascii art such that "real" drawings end up being
produced.
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: make xmldocs failed with error after 4.17 merge period
From: Heikki Krogerus @ 2018-04-06 9:11 UTC (permalink / raw)
To: Greg KH; +Cc: Masanari Iida, linux-kernel, linux-doc, Jonathan Corbet,
linux-usb
In-Reply-To: <20180406083010.GA20174@kroah.com>
On Fri, Apr 06, 2018 at 10:30:10AM +0200, Greg KH wrote:
> On Fri, Apr 06, 2018 at 11:15:55AM +0300, Heikki Krogerus wrote:
> > On Fri, Apr 06, 2018 at 09:57:34AM +0200, Greg KH wrote:
> > > On Fri, Apr 06, 2018 at 10:51:09AM +0300, Heikki Krogerus wrote:
> > > > On Fri, Apr 06, 2018 at 12:38:42PM +0900, Masanari Iida wrote:
> > > > > After merge following patch during 4.17 merger period,
> > > > > make xmldocs start to fail with error.
> > > > >
> > > > > [bdecb33af34f79cbfbb656661210f77c8b8b5b5f]
> > > > > usb: typec: API for controlling USB Type-C Multiplexers
> > > > >
> > > > > Error messages.
> > > > > reST markup error:
> > > > > /home/iida/Repo/linux-2.6/Documentation/driver-api/usb/typec.rst:215:
> > > > > (SEVERE/4) Unexpected section title or transition.
> > > > >
> > > > > ------------------------
> > > > > Documentation/Makefile:93: recipe for target 'xmldocs' failed
> > > > > make[1]: *** [xmldocs] Error 1
> > > > > Makefile:1527: recipe for target 'xmldocs' failed
> > > > > make: *** [xmldocs] Error 2
> > > > >
> > > > > $
> > > > >
> > > > > An ascii graphic in typec.rst cause the error.
> > > >
> > > > Thanks for the report. I'm going to propose that we fix this by
> > > > marking the ascii art as comment:
> > > >
> > > > diff --git a/Documentation/driver-api/usb/typec.rst b/Documentation/driver-api/usb/typec.rst
> > > > index feb31946490b..972c11bf4141 100644
> > > > --- a/Documentation/driver-api/usb/typec.rst
> > > > +++ b/Documentation/driver-api/usb/typec.rst
> > > > @@ -212,7 +212,7 @@ port drivers can use USB Role Class API with those.
> > > >
> > > > Illustration of the muxes behind a connector that supports an alternate mode:
> > > >
> > > > - ------------------------
> > > > +.. ------------------------
> > > > | Connector |
> > > > ------------------------
> > > > | |
> > > >
> > > > I hope that works.
> > >
> > > Try it and see! :)
> >
> > It will fix this issue. I was just wondering if use of ascii art is
> > acceptable in general with the .rst files? But then again, why
> > wouldn't it be.
>
> There are ways to do this, look at how the v4l2 and I think the drm
> subsystems handle ascii art such that "real" drawings end up being
> produced.
Thanks. I did not actually find anything else except use of tables and
code-blocks in v4l documentation. Is that what you were referring?
I was propsed to use something called "Literal Block" with ascii art.
http://docutils.sourceforge.net/docs/ref/rst/restructuredtext.html#literal-blocks
Unless you object, that's what I will use.
Thanks,
--
heikki
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] Documentation: typec.rst: Mark ascii art as a comment
From: Heikki Krogerus @ 2018-04-06 9:12 UTC (permalink / raw)
To: Greg KH, Jonathan Corbet
Cc: Masanari Iida, linux-kernel, linux-doc, linux-usb
In-Reply-To: <20180406082229.55375-1-heikki.krogerus@linux.intel.com>
On Fri, Apr 06, 2018 at 11:22:29AM +0300, Heikki Krogerus wrote:
> To prevent processing of ascii art as reStructuredText
> elements, marking it as a comment.
I will change this, and use literal-block instead.
> Reported-by: Masanari Iida <standby24x7@gmail.com>
> Fixes: bdecb33af34f ("usb: typec: API for controlling USB Type-C Multiplexers")
> Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
> ---
> Documentation/driver-api/usb/typec.rst | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/driver-api/usb/typec.rst b/Documentation/driver-api/usb/typec.rst
> index feb31946490b..972c11bf4141 100644
> --- a/Documentation/driver-api/usb/typec.rst
> +++ b/Documentation/driver-api/usb/typec.rst
> @@ -212,7 +212,7 @@ port drivers can use USB Role Class API with those.
>
> Illustration of the muxes behind a connector that supports an alternate mode:
>
> - ------------------------
> +.. ------------------------
> | Connector |
> ------------------------
> | |
Thanks,
--
heikki
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] Documentation: typec.rst: Mark ascii art as a comment
From: Jani Nikula @ 2018-04-06 9:19 UTC (permalink / raw)
To: Heikki Krogerus, Greg KH, Jonathan Corbet
Cc: Masanari Iida, linux-kernel, linux-doc, linux-usb
In-Reply-To: <20180406082229.55375-1-heikki.krogerus@linux.intel.com>
On Fri, 06 Apr 2018, Heikki Krogerus <heikki.krogerus@linux.intel.com> wrote:
> To prevent processing of ascii art as reStructuredText
> elements, marking it as a comment.
Please don't. This hides the ascii art from the generated documentation.
The right fix is to use a reStructuredText literal block like this:
diff --git a/Documentation/driver-api/usb/typec.rst b/Documentation/driver-api/usb/typec.rst
index feb31946490b..48ff58095f11 100644
--- a/Documentation/driver-api/usb/typec.rst
+++ b/Documentation/driver-api/usb/typec.rst
@@ -210,7 +210,7 @@ If the connector is dual-role capable, there may also be a switch for the data
role. USB Type-C Connector Class does not supply separate API for them. The
port drivers can use USB Role Class API with those.
-Illustration of the muxes behind a connector that supports an alternate mode:
+Illustration of the muxes behind a connector that supports an alternate mode::
------------------------
| Connector |
BR,
Jani.
>
> Reported-by: Masanari Iida <standby24x7@gmail.com>
> Fixes: bdecb33af34f ("usb: typec: API for controlling USB Type-C Multiplexers")
> Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
> ---
> Documentation/driver-api/usb/typec.rst | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/driver-api/usb/typec.rst b/Documentation/driver-api/usb/typec.rst
> index feb31946490b..972c11bf4141 100644
> --- a/Documentation/driver-api/usb/typec.rst
> +++ b/Documentation/driver-api/usb/typec.rst
> @@ -212,7 +212,7 @@ port drivers can use USB Role Class API with those.
>
> Illustration of the muxes behind a connector that supports an alternate mode:
>
> - ------------------------
> +.. ------------------------
> | Connector |
> ------------------------
> | |
--
Jani Nikula, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: make xmldocs failed with error after 4.17 merge period
From: Markus Heiser @ 2018-04-06 10:03 UTC (permalink / raw)
To: Heikki Krogerus
Cc: Greg KH, Masanari Iida, linux-kernel, Linux Doc Mailing List,
Jonathan Corbet, linux-usb
In-Reply-To: <20180406091126.GC21589@kuha.fi.intel.com>
> Am 06.04.2018 um 11:11 schrieb Heikki Krogerus <heikki.krogerus@linux.intel.com>:
[...]
>>>>>> An ascii graphic in typec.rst cause the error.
>>>>>
>>>>> Thanks for the report. I'm going to propose that we fix this by
>>>>> marking the ascii art as comment:
>>>>>
>>>>> diff --git a/Documentation/driver-api/usb/typec.rst b/Documentation/driver-api/usb/typec.rst
>>>>> index feb31946490b..972c11bf4141 100644
>>>>> --- a/Documentation/driver-api/usb/typec.rst
>>>>> +++ b/Documentation/driver-api/usb/typec.rst
>>>>> @@ -212,7 +212,7 @@ port drivers can use USB Role Class API with those.
>>>>>
>>>>> Illustration of the muxes behind a connector that supports an alternate mode:
>>>>>
>>>>> - ------------------------
>>>>> +.. ------------------------
>>>>> | Connector |
>>>>> ------------------------
>>>>> | |
>>>>>
>>>>> I hope that works.
>>>>
>>>> Try it and see! :)
>>>
>>> It will fix this issue. I was just wondering if use of ascii art is
>>> acceptable in general with the .rst files? But then again, why
>>> wouldn't it be.
[...]
> I was propsed to use something called "Literal Block" with ascii art.
> http://docutils.sourceforge.net/docs/ref/rst/restructuredtext.html#literal-blocks
about *ASCII-art*: see fix from Jani ...
https://www.mail-archive.com/linux-doc@vger.kernel.org/msg19302.html
where the '::' is a short-markup for a literal-block.
>> There are ways to do this, look at how the v4l2 and I think the drm
>> subsystems handle ascii art such that "real" drawings end up being
>> produced.
>
> Thanks. I did not actually find anything else except use of tables and
> code-blocks in v4l documentation. Is that what you were referring?
If it is about *figures*: we have a directive named 'kernel-figure',
which is a full replacement of the 'figure' directive from Sphinx-Doc.
In addition it supports *inline* SVG and DOT markups. Read:
https://www.kernel.org/doc/html/latest/doc-guide/sphinx.html#figures-images
-- Markus --
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: make xmldocs failed with error after 4.17 merge period
From: Heikki Krogerus @ 2018-04-06 10:51 UTC (permalink / raw)
To: Markus Heiser
Cc: Greg KH, Masanari Iida, linux-kernel, Linux Doc Mailing List,
Jonathan Corbet, linux-usb
In-Reply-To: <2A917B38-AFF6-44DC-A4A9-796B2BE560E2@darmarit.de>
Hi Markus,
On Fri, Apr 06, 2018 at 12:03:55PM +0200, Markus Heiser wrote:
> >> There are ways to do this, look at how the v4l2 and I think the drm
> >> subsystems handle ascii art such that "real" drawings end up being
> >> produced.
> >
> > Thanks. I did not actually find anything else except use of tables and
> > code-blocks in v4l documentation. Is that what you were referring?
>
> If it is about *figures*: we have a directive named 'kernel-figure',
> which is a full replacement of the 'figure' directive from Sphinx-Doc.
> In addition it supports *inline* SVG and DOT markups. Read:
>
> https://www.kernel.org/doc/html/latest/doc-guide/sphinx.html#figures-images
Thanks for the info.
I don't want to use for example dot language in kernel documentation.
I want to be able to clearly see the figure also from the plain text
file. That's why I prefer ascii art.
Isn't there a way we could render ascii art as svg diagram?
Br,
--
heikki
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: make xmldocs failed with error after 4.17 merge period
From: Markus Heiser @ 2018-04-06 11:38 UTC (permalink / raw)
To: Heikki Krogerus, johannes
Cc: Greg KH, Masanari Iida, LKML, Linux Doc Mailing List,
Jonathan Corbet, linux-usb
In-Reply-To: <20180406105139.GA28862@kuha.fi.intel.com>
> Am 06.04.2018 um 12:51 schrieb Heikki Krogerus <heikki.krogerus@linux.intel.com>:
>
> Hi Markus,
>
> On Fri, Apr 06, 2018 at 12:03:55PM +0200, Markus Heiser wrote:
>>>> There are ways to do this, look at how the v4l2 and I think the drm
>>>> subsystems handle ascii art such that "real" drawings end up being
>>>> produced.
>>>
>>> Thanks. I did not actually find anything else except use of tables and
>>> code-blocks in v4l documentation. Is that what you were referring?
>>
>> If it is about *figures*: we have a directive named 'kernel-figure',
>> which is a full replacement of the 'figure' directive from Sphinx-Doc.
>> In addition it supports *inline* SVG and DOT markups. Read:
>>
>> https://www.kernel.org/doc/html/latest/doc-guide/sphinx.html#figures-images
>
> Thanks for the info.
>
> I don't want to use for example dot language in kernel documentation.
> I want to be able to clearly see the figure also from the plain text
> file. That's why I prefer ascii art.
>
> Isn't there a way we could render ascii art as svg diagram?
Sorry, not yet. Johannes started a discussion about this. Its a long
time ago and I do not have any new ideas yet :/ see:
https://www.mail-archive.com/linux-doc@vger.kernel.org/msg07035.html
-- Markus --
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v2] Documentation: typec.rst: Use literal-block element with ascii art
From: Heikki Krogerus @ 2018-04-06 12:41 UTC (permalink / raw)
To: Greg KH, Jonathan Corbet
Cc: Masanari Iida, linux-kernel, linux-doc, Markus Heiser,
Jani Nikula, linux-usb
Using reStructuredText literal-block element with ascii-art.
That prevents the ascii art from being processed as
reStructuredText.
Reported-by: Masanari Iida <standby24x7@gmail.com>
Fixes: bdecb33af34f ("usb: typec: API for controlling USB Type-C Multiplexers")
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
---
Changed since v1:
- Using literal-block element instead of comment
- Subject in v1 was "Documentation: typec.rst: Mark ascii art as a comment"
---
Documentation/driver-api/usb/typec.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/driver-api/usb/typec.rst b/Documentation/driver-api/usb/typec.rst
index feb31946490b..48ff58095f11 100644
--- a/Documentation/driver-api/usb/typec.rst
+++ b/Documentation/driver-api/usb/typec.rst
@@ -210,7 +210,7 @@ If the connector is dual-role capable, there may also be a switch for the data
role. USB Type-C Connector Class does not supply separate API for them. The
port drivers can use USB Role Class API with those.
-Illustration of the muxes behind a connector that supports an alternate mode:
+Illustration of the muxes behind a connector that supports an alternate mode::
------------------------
| Connector |
--
2.16.3
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH v2] Documentation: typec.rst: Use literal-block element with ascii art
From: Jani Nikula @ 2018-04-06 14:10 UTC (permalink / raw)
To: Heikki Krogerus, Greg KH, Jonathan Corbet
Cc: Masanari Iida, linux-kernel, linux-doc, Markus Heiser, linux-usb
In-Reply-To: <20180406124122.70676-1-heikki.krogerus@linux.intel.com>
On Fri, 06 Apr 2018, Heikki Krogerus <heikki.krogerus@linux.intel.com> wrote:
> Using reStructuredText literal-block element with ascii-art.
> That prevents the ascii art from being processed as
> reStructuredText.
>
> Reported-by: Masanari Iida <standby24x7@gmail.com>
> Fixes: bdecb33af34f ("usb: typec: API for controlling USB Type-C Multiplexers")
> Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Reviewed-and-tested-by: Jani Nikula <jani.nikula@intel.com>
> ---
> Changed since v1:
> - Using literal-block element instead of comment
> - Subject in v1 was "Documentation: typec.rst: Mark ascii art as a comment"
> ---
> Documentation/driver-api/usb/typec.rst | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/driver-api/usb/typec.rst b/Documentation/driver-api/usb/typec.rst
> index feb31946490b..48ff58095f11 100644
> --- a/Documentation/driver-api/usb/typec.rst
> +++ b/Documentation/driver-api/usb/typec.rst
> @@ -210,7 +210,7 @@ If the connector is dual-role capable, there may also be a switch for the data
> role. USB Type-C Connector Class does not supply separate API for them. The
> port drivers can use USB Role Class API with those.
>
> -Illustration of the muxes behind a connector that supports an alternate mode:
> +Illustration of the muxes behind a connector that supports an alternate mode::
>
> ------------------------
> | Connector |
--
Jani Nikula, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net-next 00/12] fscache: Fixes, traces and development
From: Matthew Wilcox @ 2018-04-06 21:02 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Jonathan Corbet, linux-doc
In-Reply-To: <CA+55aFx_fs7C6JAX_ORJ9MoXEp25LcXS0CUnK4aO4p=hQw6xOg@mail.gmail.com>
On Fri, Apr 06, 2018 at 11:32:11AM -0700, Linus Torvalds wrote:
> On Fri, Apr 6, 2018 at 11:21 AM, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> >
> > No, but if you can redo the pull request part so that the diffstat I
> > get will match the diffstat I see in the pull request, that would be
> > good.
>
> Oh, and can you please make sure there is a "[GIT PULL]" in the
> subject line for your pull requests?
>
> Particularly during the merge window (not so much later) I end up
> having a separate filtered list of emails that I look at that mention
> "git pull".
>
> Your pull requests don't seem to match that, so your pull requests
> don't actually even show up in my list of pending pull requests.
We have out of date information in Documentation ...
Jon, please consider applying:
diff --git a/Documentation/process/submitting-patches.rst b/Documentation/process/submitting-patches.rst
index f7152ed565e5..908bb55be407 100644
--- a/Documentation/process/submitting-patches.rst
+++ b/Documentation/process/submitting-patches.rst
@@ -761,7 +761,7 @@ requests, especially from new, unknown developers. If in doubt you can use
the pull request as the cover letter for a normal posting of the patch
series, giving the maintainer the option of using either.
-A pull request should have [GIT] or [PULL] in the subject line. The
+A pull request should have [GIT PULL] in the subject line. The
request itself should include the repository name and the branch of
interest on a single line; it should look something like::
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH net-next 00/12] fscache: Fixes, traces and development
From: Linus Torvalds @ 2018-04-06 21:16 UTC (permalink / raw)
To: Matthew Wilcox; +Cc: Jonathan Corbet, open list:DOCUMENTATION
In-Reply-To: <20180406210235.GB9618@bombadil.infradead.org>
On Fri, Apr 6, 2018 at 2:02 PM, Matthew Wilcox <willy@infradead.org> wrote:
>
> We have out of date information in Documentation ...
My match is actually fairly lax.
As long as the email has both "git" and "pull" somewhere, I should see
it. It doesn't actually have to be in the subject line.
And almost always the "git" is there anyway, and DavidH's email had
that one at least twice, in just one line:
> git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git
and a lot of people end up having some boiler-plate that says "Please
pull" or something, so they get the "pull" part that way too, and I'll
see those emails even when they have nothing at all in the subject
line.
But yes:
> Jon, please consider applying:
>
> diff --git a/Documentation/process/submitting-patches.rst b/Documentation/process/submitting-patches.rst
> index f7152ed565e5..908bb55be407 100644
> --- a/Documentation/process/submitting-patches.rst
> +++ b/Documentation/process/submitting-patches.rst
> -A pull request should have [GIT] or [PULL] in the subject line. The
> +A pull request should have [GIT PULL] in the subject line. The
That's the *safest* thing to have, in that now the subject line itself
already covers everything, and doesn't depend on anything else being
implicitly in the message itself.
And it's what most people seem to use, based on what I see. It makes
them stand out visually to humans too, not just to my usual filter.
Having "PATCH" in the subject like (like DavidH _does_ have) also ends
up being something I look for, but not during the first week of the
merge window when I'm overwhelmed by pull requests. I usually do that
at the very end of the merge window just to try to make sure
(sometimes even successfully) that I didn't miss anything.
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: make xmldocs failed with error after 4.17 merge period
From: Johannes Berg @ 2018-04-07 19:19 UTC (permalink / raw)
To: Markus Heiser, Heikki Krogerus
Cc: Greg KH, Masanari Iida, LKML, Linux Doc Mailing List,
Jonathan Corbet, linux-usb
In-Reply-To: <B8BFEE5C-F2CF-485D-80D6-8EC31EE2429C@darmarit.de>
On Fri, 2018-04-06 at 13:38 +0200, Markus Heiser wrote:
>
> Sorry, not yet. Johannes started a discussion about this. Its a long
> time ago and I do not have any new ideas yet :/ see:
>
> https://www.mail-archive.com/linux-doc@vger.kernel.org/msg07035.html
I still think the tools themselves don't matter all that much, as long
as there aren't totally onerous requirements. I'd argue pretty much
everything available on a modern distro would be OK provided we have a
reasonable fallback (e.g. to ASCII as I had even written), along with
some sort of documentation of dependencies, or perhaps better, some
command line option to gather the info dynamically.
But then again, I've already said pretty much this a year and a half ago
and most people seemed more interested in some kind of purity argument
than having better documentation :-)
johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox