* [cip-dev] [ANNOUNCE] Release v4.19.103-cip20 and v4.4.213-cip42
From: nobuhiro1.iwamatsu at toshiba.co.jp @ 2020-02-14 20:32 UTC (permalink / raw)
To: cip-dev
Hi,
CIP kernel team has released Linux kernel v4.19.103-cip20 and v4.4.213-cip42.
The linux-4.19.y-cip tree has been updated base version from v4.19.98 to v4.19.103,
and many features of r8a774b1 have been added.
Then the linux-4.4.y-cip tree has been updated base version from v4.4.208 to v4.4.213,
and QSPI, TPU, PWM, VSP, USB and MSIOF support for r8a7744 has been added.
We can get this release via the git tree at:
v4.19.103-cip20:
repository:
https://git.kernel.org/pub/scm/linux/kernel/git/cip/linux-cip.git
branch:
linux-4.19.y-cip
commit hash:
d8d2f780968e403b42ecf61d498032ade45546d0
added commits:
CIP: Bump version suffix to -cip20 after merge from stable
arm64: dts: renesas: r8a774b1: Add USB3.0 device nodes
arm64: dts: renesas: r8a774b1: Add USB-DMAC and HSUSB device nodes
arm64: dts: renesas: r8a774b1: Add USB2.0 phy and host (EHCI/OHCI) device nodes
dt-bindings: usb: renesas_usb3: Document r8a774b1 support
dt-bindings: usb: renesas_gen3: Rename bindings documentation file to reflect IP block
dt-bindings: usb-xhci: Add r8a774b1 support
dt-bindings: rcar-gen3-phy-usb3: Add r8a774b1 support
dt-bindings: usb: renesas_usbhs: Add r8a774b1 support
dt-bindings: usb: renesas_usbhs: Rename bindings documentation file
dt-bindings: dmaengine: usb-dmac: Add binding for r8a774b1
dt-bindings: rcar-gen3-phy-usb2: Add r8a774b1 support
arm64: dts: renesas: r8a774b1: Add Sound and Audio DMAC device nodes
ASoC: rsnd: Document r8a774b1 bindings
arm64: dts: renesas: r8a774a1: Remove audio port node
arm64: dts: renesas: Add support for Advantech idk-1110wr LVDS panel
arm64: dts: renesas: hihope-rzg2-ex: Add LVDS support
drm: rcar-du: lvds: Add r8a774b1 support
arm64: dts: renesas: hihope-rzg2-ex: Enable backlight
arm64: dts: renesas: r8a774b1: Add PWM device nodes
arm64: dts: renesas: r8a774b1: Add FDP1 device nodes
arm64: dts: renesas: r8a774b1-hihope-rzg2n: Add display clock properties
arm64: dts: renesas: r8a774b1: Add HDMI encoder instance
arm64: dts: renesas: r8a774b1: Add DU device to DT
drm: rcar-du: Add R8A774B1 support
arm64: dts: renesas: hihope-common: Move du clk properties out of common dtsi
arm64: dts: renesas: r8a774b1: Connect Ethernet-AVB to IPMMU-DS0
arm64: dts: renesas: r8a774b1: Tie SYS-DMAC to IPMMU-DS0/1
arm64: dts: renesas: r8a774b1: Add VSP instances
arm64: dts: renesas: r8a774b1: Add FCPF and FCPV instances
arm64: dts: renesas: r8a774b1: Add IPMMU device nodes
iommu/ipmmu-vmsa: Hook up r8a774b1 DT matching code
dt-bindings: iommu: ipmmu-vmsa: Add r8a774b1 support
arm64: dts: renesas: r8a774b1: Add CAN and CAN FD support
dt-bindings: can: rcar_canfd: document r8a774b1 support
dt-bindings: can: rcar_can: document r8a774b1 support
arm64: dts: renesas: r8a774b1: Add TMU device nodes
clk: renesas: r8a774b1: Add TMU clock
dt-bindings: timer: renesas: tmu: Document r8a774b1 bindings
arm64: dts: renesas: r8a774b1: Add CMT device nodes
dt-bindings: timer: renesas, cmt: Document r8a774b1 CMT support
arm64: dts: renesas: r8a774b1: Add RZ/G2N thermal support
thermal: rcar_gen3_thermal: Add r8a774b1 support
dt-bindings: thermal: rcar-gen3-thermal: Add r8a774b1 support
arm64: dts: renesas: r8a774b1: Add OPPs table for cpu devices
arm64: dts: renesas: r8a774b1: Add I2C and IIC-DVFS support
dt-bindings: i2c: sh_mobile: Add r8a774b1 support
dt-bindings: i2c: sh_mobile: Rename bindings documentation file
dt-bindings: i2c: rcar: Add r8a774b1 support
dt-bindings: i2c: rcar: Rename bindings documentation file
arm64: dts: renesas: r8a774b1-hihope-rzg2n: Enable HS400 mode
arm64: dts: renesas: r8a774b1: Add SDHI support
mmc: renesas_sdhi_internal_dmac: Add r8a774b1 support
dt-bindings: mmc: renesas_sdhi: Add r8a774b1 support
arm64: dts: renesas: r8a774b1: Add INTC-EX device node
arm64: dts: renesas: hihope-rzg2-ex: Let the board specific DT decide about pciec1
arm64: dts: renesas: r8a774b1: Add PCIe device nodes
arm64: dts: renesas: r8a774b1: Add all MSIOF nodes
arm64: dts: renesas: r8a774b1: Add RWDT node
dt-bindings: watchdog: renesas-wdt: Document r8a774b1 support
dt-bindings: watchdog: Rename bindings documentation file
dt-bindings: spi: sh-msiof: Add r8a774b1 support
arm64: dts: renesas: Add HiHope RZ/G2N sub board support
arm64: dts: renesas: r8a774b1: Add Ethernet AVB node
dt-bindings: net: ravb: Add support for r8a774b1 SoC
arm64: dts: renesas: r8a774b1: Add GPIO device nodes
dt-bindings: gpio: rcar: Add DT binding for r8a774b1
arm64: dts: renesas: r8a774b1: Add SCIF and HSCIF nodes
arm64: dts: renesas: r8a774b1: Add SYS-DMAC device nodes
dt-bindings: dmaengine: rcar-dmac: Document R8A774B1 bindings
v4.4.213-cip42:
repository:
https://git.kernel.org/pub/scm/linux/kernel/git/cip/linux-cip.git
branch:
linux-4.4.y-cip
commit hash:
2507dd95fec1b330c3c62881e43d3d10d44a1a04
added commits:
CIP: Bump version suffix to -cip42 after merge from stable
ARM: dts: r8a7744: Add PCIe Controller device node
ARM: dts: r8a7744: Add xhci support
dt-bindings: usb-xhci: Document r8a7744 support
usb: host: xhci-plat: Add r8a7744 support
ARM: dts: r8a7744-iwg20m: Add SPI NOR support
ARM: dts: r8a7744: Add MSIOF[012] support
ARM: dts: r8a7744: Add QSPI support
ARM: dts: r8a7744: Add TPU support
ARM: dts: r8a7744: Add PWM SoC support
ARM: dts: r8a7744: Add VSP support
Best regards,
Nobuhiro
^ permalink raw reply
* Re: [PATCH v2 20/21] target/arm: Use FIELD_EX32 for testing 32-bit fields
From: Richard Henderson @ 2020-02-14 20:32 UTC (permalink / raw)
To: Peter Maydell, qemu-arm, qemu-devel
Cc: Eric Auger, Aaron Lindsay, Philippe Mathieu-Daudé
In-Reply-To: <20200214175116.9164-21-peter.maydell@linaro.org>
On 2/14/20 9:51 AM, Peter Maydell wrote:
> Cut-and-paste errors mean we're using FIELD_EX64() to extract fields from
> some 32-bit ID register fields. Use FIELD_EX32() instead. (This makes
> no difference in behaviour, it's just more consistent.)
>
> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
> ---
> target/arm/cpu.h | 18 +++++++++---------
> 1 file changed, 9 insertions(+), 9 deletions(-)
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
r~
^ permalink raw reply
* Re: [PATCH v2 19/21] target/arm: Use isar_feature function for testing AA32HPD feature
From: Richard Henderson @ 2020-02-14 20:32 UTC (permalink / raw)
To: Peter Maydell, qemu-arm, qemu-devel
Cc: Eric Auger, Aaron Lindsay, Philippe Mathieu-Daudé
In-Reply-To: <20200214175116.9164-20-peter.maydell@linaro.org>
On 2/14/20 9:51 AM, Peter Maydell wrote:
> Now we have moved ID_MMFR4 into the ARMISARegisters struct, we
> can define and use an isar_feature for the presence of the
> ARMv8.2-AA32HPD feature, rather than open-coding the test.
>
> While we're here, correct a comment typo which missed an 'A'
> from the feature name.
>
> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
> ---
> target/arm/cpu.h | 5 +++++
> target/arm/helper.c | 4 ++--
> 2 files changed, 7 insertions(+), 2 deletions(-)
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
r~
^ permalink raw reply
* Re: [PATCH v2 18/21] target/arm: Test correct register in aa32_pan and aa32_ats1e1 checks
From: Richard Henderson @ 2020-02-14 20:30 UTC (permalink / raw)
To: Peter Maydell, qemu-arm, qemu-devel
Cc: Eric Auger, Aaron Lindsay, Philippe Mathieu-Daudé
In-Reply-To: <20200214175116.9164-19-peter.maydell@linaro.org>
On 2/14/20 9:51 AM, Peter Maydell wrote:
> The isar_feature_aa32_pan and isar_feature_aa32_ats1e1 functions
> are supposed to be testing fields in ID_MMFR3; but a cut-and-paste
> error meant we were looking at MVFR0 instead.
>
> Fix the functions to look at the right register; this requires
> us to move at least id_mmfr3 to the ARMISARegisters struct; we
> choose to move all the ID_MMFRn registers for consistency.
>
> Fixes: 3d6ad6bb466f
> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
> ---
> target/arm/cpu.h | 14 +++---
> hw/intc/armv7m_nvic.c | 8 ++--
> target/arm/cpu.c | 104 +++++++++++++++++++++---------------------
> target/arm/cpu64.c | 28 ++++++------
> target/arm/helper.c | 12 ++---
> target/arm/kvm32.c | 17 +++++++
> target/arm/kvm64.c | 10 ++++
> 7 files changed, 110 insertions(+), 83 deletions(-)
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
r~
^ permalink raw reply
* Re: [Virtio-fs] fedora packages for virtiofsd
From: Dr. David Alan Gilbert @ 2020-02-14 20:31 UTC (permalink / raw)
To: Daniel Walsh; +Cc: virtio-fs-list, Mrunal Patel, Vivek Goyal, crobinso
In-Reply-To: <b703d3ec-b48a-776a-a525-4acb16a27ac4@redhat.com>
* Daniel Walsh (dwalsh@redhat.com) wrote:
> On 2/14/20 2:44 PM, Dr. David Alan Gilbert wrote:
> > * Vivek Goyal (vgoyal@redhat.com) wrote:
> >> Hi David,
> >>
> >> Are fedora packages for latest qemu with virtiofsd now available. Can one
> >> try it?
> >>
> >> Dan Walsh and Mrunal are looking for it (CCed in email).
> >>
> >> Keeping this thread on virtio-fs list as others might be interested as
> >> well.
> > Cole has got it into the virt-preview copr:
> >
> > https://copr.fedorainfracloud.org/coprs/g/virtmaint-sig/virt-preview
> >
> > Dave
> >
> >> Thanks
> >> Vivek
> > --
> > Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
>
> How soon can we get this into Fedora. I really do not want to have to
> deal with special packages, that users can not easily get a hold of. I
> am real apprehensive on giving the go-ahead on a project as being
> Enterprise ready until it gets some soak time in Fedora. I would love
> to see this available in Fedora 32, so people can start experimenting
> with it.
Understood.
It's upstream in the current QEMU tree, but it's due for release end of
April which is I assume too late for F32.
(libvirt is still a work in progress).
I'll leave Cole to comment on Fedora backporting.
Dave
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
^ permalink raw reply
* Re: [PATCH 00/28] PM: QoS: Get rid of unuseful code and rework CPU latency QoS interface
From: Francisco Jerez @ 2020-02-14 20:32 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Rafael J. Wysocki, Rafael J. Wysocki, Linux PM, LKML,
Amit Kucheria, Pandruvada, Srinivas, Rodrigo Vivi, Peter Zijlstra
In-Reply-To: <CAJZ5v0hm2vVbM5dXGitvvUrWoZXZXXaJ+P3x38BjHRukZKgB3Q@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 6046 bytes --]
"Rafael J. Wysocki" <rafael@kernel.org> writes:
> On Fri, Feb 14, 2020 at 1:14 AM Francisco Jerez <currojerez@riseup.net> wrote:
>>
>> "Rafael J. Wysocki" <rafael@kernel.org> writes:
>>
>> > On Thu, Feb 13, 2020 at 12:34 PM Rafael J. Wysocki <rafael@kernel.org> wrote:
>
> [cut]
>
>> >
>> > I think that your use case is almost equivalent to the thermal
>> > pressure one, so you'd want to limit the max and so that would be
>> > something similar to store_max_perf_pct() with its input side hooked
>> > up to a QoS list.
>> >
>> > But it looks like that QoS list would rather be of a "reservation"
>> > type, so a request added to it would mean something like "leave this
>> > fraction of power that appears to be available to the CPU subsystem
>> > unused, because I need it for a different purpose". And in principle
>> > there might be multiple requests in there at the same time and those
>> > "reservations" would add up. So that would be a kind of "limited sum"
>> > QoS type which wasn't even there before my changes.
>> >
>> > A user of that QoS list might then do something like
>> >
>> > ret = cpu_power_reserve_add(1, 4);
>> >
>> > meaning that it wants 25% of the "potential" CPU power to be not
>> > utilized by CPU performance scaling and that could affect the
>> > scheduler through load modifications (kind of along the thermal
>> > pressure patchset discussed some time ago) and HWP (as well as the
>> > non-HWP intel_pstate by preventing turbo frequencies from being used
>> > etc).
>>
>> The problems with this are the same as with the per-CPU frequency QoS
>> approach: How does the device driver know what the appropriate fraction
>> of CPU power is?
>
> Of course it doesn't know and it may never know exactly, but it may guess.
>
> Also, it may set up a feedback loop: request an aggressive
> reservation, run for a while, measure something and refine if there's
> headroom. Then repeat.
>
Yeah, of course, but that's obviously more computationally intensive and
less accurate than computing an approximately optimal constraint in a
single iteration (based on knowledge from performance counters and a
notion of the latency requirements of the application), since such a
feedback loop relies on repeatedly overshooting and undershooting the
optimal value (the latter causes an artificial CPU bottleneck, possibly
slowing down other applications too) in order to converge to and remain
in a neighborhood of the optimal value.
Incidentally people tested a power balancing solution with a feedback
loop very similar to the one you're describing side by side to the RFC
patch series I provided a link to earlier (which targeted Gen9 LP
parts), and the energy efficiency improvements they observed were
roughly half of the improvement obtained with my series unsurprisingly.
Not to speak about generalizing such a feedback loop to bottlenecks on
multiple I/O devices.
>> Depending on the instantaneous behavior of the
>> workload it might take 1% or 95% of the CPU power in order to keep the
>> IO device busy. Each user of this would need to monitor the performance
>> of every CPU in the system and update the constraints on each of them
>> periodically (whether or not they're talking to that IO device, which
>> would possibly negatively impact the latency of unrelated applications
>> running on other CPUs, unless we're willing to race with the task
>> scheduler).
>
> No, it just needs to measure a signal representing how much power *it*
> gets and decide whether or not it can let the CPU subsystem use more
> power.
>
Well yes it's technically possible to set frequency constraints based on
trial-and-error without sampling utilization information from the CPU
cores, but don't we agree that this kind of information can be highly
valuable?
>> A solution based on utilization clamps (with some
>> extensions) sounds more future-proof to me honestly.
>
> Except that it would be rather hard to connect it to something like
> RAPL, which should be quite straightforward with the approach I'm
> talking about.
>
I think using RAPL as additional control variable would be useful, but
fully orthogonal to the cap being set by some global mechanism or being
derived from the aggregation of a number of per-process power caps based
on the scheduler behavior. The latter sounds like the more reasonable
fit for a multi-tasking, possibly virtualized environment honestly.
Either way RAPL is neither necessary nor sufficient in order to achieve
the energy efficiency improvement I'm working on.
> The problem with all scheduler-based ways, again, is that there is no
> direct connection between the scheduler and HWP,
I was planning to introduce such a connection in RFC part 2. I have a
prototype for that based on a not particularly pretty custom interface,
I wouldn't mind trying to get it to use utilization clamps if you think
that's the way forward.
> or even with whatever the processor does with the P-states in the
> turbo range. If any P-state in the turbo range is requested, the
> processor has a license to use whatever P-state it wants, so this
> pretty much means allowing it to use as much power as it can.
>
> So in the first place, if you want to limit the use of power in the
> CPU subsystem through frequency control alone, you need to prevent it
> from using turbo P-states at all. However, with RAPL you can just
> limit power which may still allow some (but not all) turbo P-states to
> be used.
My goal is not to limit the use of power of the CPU (if it has enough
load to utilize 100% of the cycles at turbo frequency so be it), but to
get it to use it more efficiently. If you are constrained by a given
power budget (e.g. the TDP or the one you want set via RAPL) you can do
more with it if you set a stable frequency rather than if you let the
CPU bounce back and forth between turbo and idle. This can only be
achieved effectively if the frequency governor has a rough idea of the
latency requirements of the workload, since it involves a
latency/energy-efficiency trade-off.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]
^ permalink raw reply
* Re: Buffered IO async context overhead
From: Andres Freund @ 2020-02-14 20:31 UTC (permalink / raw)
To: Jens Axboe; +Cc: io-uring
In-Reply-To: <c91551b2-9694-78cb-2aa6-bc8cccc474c3@kernel.dk>
Hi,
On 2020-02-14 13:13:35 -0700, Jens Axboe wrote:
> On 2/14/20 12:50 PM, Andres Freund wrote:
> > which I think is pretty clear evidence we're hitting fairly significant
> > contention on the queue lock.
> >
> >
> > I am hitting this in postgres originally, not fio, but I thought it's
> > easier to reproduce this way. There's obviously benefit to doing things
> > in the background - but it requires odd logic around deciding when to
> > use io_uring, and when not.
> >
> > To be clear, none of this happens with DIO, but I don't forsee switching
> > to DIO for all IO by default ever (too high demands on accurate
> > configuration).
>
> Can you try with this added?
>
>
> diff --git a/fs/io_uring.c b/fs/io_uring.c
> index 76cbf474c184..207daf83f209 100644
> --- a/fs/io_uring.c
> +++ b/fs/io_uring.c
> @@ -620,6 +620,7 @@ static const struct io_op_def io_op_defs[] = {
> .async_ctx = 1,
> .needs_mm = 1,
> .needs_file = 1,
> + .hash_reg_file = 1,
> .unbound_nonreg_file = 1,
> },
> [IORING_OP_WRITEV] = {
> @@ -634,6 +635,7 @@ static const struct io_op_def io_op_defs[] = {
> },
> [IORING_OP_READ_FIXED] = {
> .needs_file = 1,
> + .hash_reg_file = 1,
> .unbound_nonreg_file = 1,
> },
> [IORING_OP_WRITE_FIXED] = {
> @@ -711,11 +713,13 @@ static const struct io_op_def io_op_defs[] = {
> [IORING_OP_READ] = {
> .needs_mm = 1,
> .needs_file = 1,
> + .hash_reg_file = 1,
> .unbound_nonreg_file = 1,
> },
> [IORING_OP_WRITE] = {
> .needs_mm = 1,
> .needs_file = 1,
> + .hash_reg_file = 1,
> .unbound_nonreg_file = 1,
> },
> [IORING_OP_FADVISE] = {
> @@ -955,7 +959,7 @@ static inline bool io_prep_async_work(struct io_kiocb *req,
> bool do_hashed = false;
>
> if (req->flags & REQ_F_ISREG) {
> - if (def->hash_reg_file)
> + if (!(req->kiocb->ki_flags & IOCB_DIRECT) && def->hash_reg_file)
> do_hashed = true;
> } else {
> if (def->unbound_nonreg_file)
I can (will do Sunday, on the road till then). But I'm a bit doubtful
it'll help. This is using WRITEV after all, and I only see a single
worker?
Greetings,
Andres Freund
^ permalink raw reply
* Re: [PATCH 06/10] riscv: Add Kendryte K210 SoC support
From: Sean Anderson @ 2020-02-14 20:31 UTC (permalink / raw)
To: linux-riscv
In-Reply-To: <20200212103432.660256-7-damien.lemoal@wdc.com>
Hi Damien/Chistopher,
I'm working on adding k210 support to U-Boot [1], so I'm interested in
how you've tackled these problems. Hopefully, we can keep the
implementations broadly similar, to make it easier to correct bugs in
the future. In part
[1] https://patchwork.ozlabs.org/project/uboot/list/?series=157821
On 2/12/20 5:34 AM, Damien Le Moal wrote:
> From: Christoph Hellwig <hch@lst.de>
>
> Add support for the Kendryte K210 RISC-V SoC. For now, this support
> only provides a simple sysctl driver allowing to setup the CPU and
> uart clock. This support is enabled through the new Kconfig option
> SOC_KENDRYTE and defines the config option CONFIG_K210_SYSCTL
> to enable the K210 SoC sysctl driver compilation.
>
> The sysctl driver also registers an early SoC initialization function
> allowing enabling the general purpose use of the 2MB of SRAM normally
> reserved for the SoC AI engine. This initialization function is
> automatically called before the dt early initialization using the flat
> dt root node compatible property matching the value "kendryte,k210".
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
> ---
> arch/riscv/Kconfig.socs | 6 +
> drivers/soc/Kconfig | 1 +
> drivers/soc/Makefile | 1 +
> drivers/soc/kendryte/Kconfig | 14 ++
> drivers/soc/kendryte/Makefile | 3 +
> drivers/soc/kendryte/k210-sysctl.c | 245 +++++++++++++++++++++++++++++
> 6 files changed, 270 insertions(+)
> create mode 100644 drivers/soc/kendryte/Kconfig
> create mode 100644 drivers/soc/kendryte/Makefile
> create mode 100644 drivers/soc/kendryte/k210-sysctl.c
>
> diff --git a/arch/riscv/Kconfig.socs b/arch/riscv/Kconfig.socs
> index d325b67d00df..4d5d4a65b2a2 100644
> --- a/arch/riscv/Kconfig.socs
> +++ b/arch/riscv/Kconfig.socs
> @@ -10,4 +10,10 @@ config SOC_SIFIVE
> help
> This enables support for SiFive SoC platform hardware.
>
> +config SOC_KENDRYTE
> + bool "Kendryte K210 SoC"
> + depends on !MMU
> + help
> + This enables support for Kendryte K210 SoC hardware.
> +
> endmenu
> diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
> index 1778f8c62861..425ab6f7e375 100644
> --- a/drivers/soc/Kconfig
> +++ b/drivers/soc/Kconfig
> @@ -22,5 +22,6 @@ source "drivers/soc/ux500/Kconfig"
> source "drivers/soc/versatile/Kconfig"
> source "drivers/soc/xilinx/Kconfig"
> source "drivers/soc/zte/Kconfig"
> +source "drivers/soc/kendryte/Kconfig"
>
> endmenu
> diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile
> index 8b49d782a1ab..af58063bb989 100644
> --- a/drivers/soc/Makefile
> +++ b/drivers/soc/Makefile
> @@ -28,3 +28,4 @@ obj-$(CONFIG_ARCH_U8500) += ux500/
> obj-$(CONFIG_PLAT_VERSATILE) += versatile/
> obj-y += xilinx/
> obj-$(CONFIG_ARCH_ZX) += zte/
> +obj-$(CONFIG_SOC_KENDRYTE) += kendryte/
> diff --git a/drivers/soc/kendryte/Kconfig b/drivers/soc/kendryte/Kconfig
> new file mode 100644
> index 000000000000..49785b1b0217
> --- /dev/null
> +++ b/drivers/soc/kendryte/Kconfig
> @@ -0,0 +1,14 @@
> +# SPDX-License-Identifier: GPL-2.0
> +
> +if SOC_KENDRYTE
> +
> +config K210_SYSCTL
> + bool "Kendryte K210 system controller"
> + default y
> + depends on RISCV
> + help
> + Enables controlling the K210 various clocks and to enable
> + general purpose use of the extra 2MB of SRAM normally
> + reserved for the AI engine.
> +
> +endif
> diff --git a/drivers/soc/kendryte/Makefile b/drivers/soc/kendryte/Makefile
> new file mode 100644
> index 000000000000..002d9ce95c0d
> --- /dev/null
> +++ b/drivers/soc/kendryte/Makefile
> @@ -0,0 +1,3 @@
> +# SPDX-License-Identifier: GPL-2.0
> +
> +obj-$(CONFIG_K210_SYSCTL) += k210-sysctl.o
> diff --git a/drivers/soc/kendryte/k210-sysctl.c b/drivers/soc/kendryte/k210-sysctl.c
> new file mode 100644
> index 000000000000..7d4ecd954af0
> --- /dev/null
> +++ b/drivers/soc/kendryte/k210-sysctl.c
> @@ -0,0 +1,245 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Copyright (c) 2019 Christoph Hellwig.
> + * Copyright (c) 2019 Western Digital Corporation or its affiliates.
> + */
> +#include <linux/types.h>
> +#include <linux/io.h>
> +#include <linux/of.h>
> +#include <linux/platform_device.h>
> +#include <linux/clk-provider.h>
> +#include <linux/clkdev.h>
> +#include <asm/soc.h>
> +
> +#define K210_SYSCTL_CLK0_FREQ 26000000UL
> +
> +/* Registers base address */
> +#define K210_SYSCTL_SYSCTL_BASE_ADDR 0x50440000ULL
> +
> +/* Registers */
> +#define K210_SYSCTL_PLL0 0x08
> +#define K210_SYSCTL_PLL1 0x0c
> +/* clkr: 4bits, clkf1: 6bits, clkod: 4bits, bwadj: 4bits */
> +#define PLL_RESET (1 << 20)
> +#define PLL_PWR (1 << 21)
> +#define PLL_INTFB (1 << 22)
> +#define PLL_BYPASS (1 << 23)
> +#define PLL_TEST (1 << 24)
> +#define PLL_OUT_EN (1 << 25)
> +#define PLL_TEST_EN (1 << 26)
> +#define K210_SYSCTL_PLL_LOCK 0x18
> +#define PLL0_LOCK1 (1 << 0)
> +#define PLL0_LOCK2 (1 << 1)
> +#define PLL0_SLIP_CLEAR (1 << 2)
> +#define PLL0_TEST_CLK_OUT (1 << 3)
> +#define PLL1_LOCK1 (1 << 8)
> +#define PLL1_LOCK2 (1 << 9)
> +#define PLL1_SLIP_CLEAR (1 << 10)
> +#define PLL1_TEST_CLK_OUT (1 << 11)
> +#define PLL2_LOCK1 (1 << 16)
> +#define PLL2_LOCK2 (1 << 16)
> +#define PLL2_SLIP_CLEAR (1 << 18)
> +#define PLL2_TEST_CLK_OUT (1 << 19)
> +#define K210_SYSCTL_CLKSEL0 0x20
> +#define CLKSEL_ACLK (1 << 0)
> +#define K210_SYSCTL_CLKEN_CENT 0x28
> +#define CLKEN_CPU (1 << 0)
> +#define CLKEN_SRAM0 (1 << 1)
> +#define CLKEN_SRAM1 (1 << 2)
> +#define CLKEN_APB0 (1 << 3)
> +#define CLKEN_APB1 (1 << 4)
> +#define CLKEN_APB2 (1 << 5)
> +#define K210_SYSCTL_CLKEN_PERI 0x2c
> +#define CLKEN_ROM (1 << 0)
> +#define CLKEN_DMA (1 << 1)
> +#define CLKEN_AI (1 << 2)
> +#define CLKEN_DVP (1 << 3)
> +#define CLKEN_FFT (1 << 4)
> +#define CLKEN_GPIO (1 << 5)
> +#define CLKEN_SPI0 (1 << 6)
> +#define CLKEN_SPI1 (1 << 7)
> +#define CLKEN_SPI2 (1 << 8)
> +#define CLKEN_SPI3 (1 << 9)
> +#define CLKEN_I2S0 (1 << 10)
> +#define CLKEN_I2S1 (1 << 11)
> +#define CLKEN_I2S2 (1 << 12)
> +#define CLKEN_I2C0 (1 << 13)
> +#define CLKEN_I2C1 (1 << 14)
> +#define CLKEN_I2C2 (1 << 15)
> +#define CLKEN_UART1 (1 << 16)
> +#define CLKEN_UART2 (1 << 17)
> +#define CLKEN_UART3 (1 << 18)
> +#define CLKEN_AES (1 << 19)
> +#define CLKEN_FPIO (1 << 20)
> +#define CLKEN_TIMER0 (1 << 21)
> +#define CLKEN_TIMER1 (1 << 22)
> +#define CLKEN_TIMER2 (1 << 23)
> +#define CLKEN_WDT0 (1 << 24)
> +#define CLKEN_WDT1 (1 << 25)
> +#define CLKEN_SHA (1 << 26)
> +#define CLKEN_OTP (1 << 27)
> +#define CLKEN_RTC (1 << 29)
> +
> +struct k210_sysctl {
> + void __iomem *regs;
> + struct clk_hw hw;
> +};
> +
> +static void k210_set_bits(u32 val, void __iomem *reg)
> +{
> + writel(readl(reg) | val, reg);
> +}
> +
> +static void k210_clear_bits(u32 val, void __iomem *reg)
> +{
> + writel(readl(reg) & ~val, reg);
> +}
> +
> +static void k210_pll1_enable(void __iomem *regs)
> +{
> + u32 val;
> +
> + val = readl(regs + K210_SYSCTL_PLL1);
> + val &= ~0xfffff;
> + val |= (59 << 4) | (3 << 10) | (59 << 15);
Can this be done with symbolic constants? Additionally, I believe bwadj
needs to be set to the value you use for f (at least when using internal
feedback). There is a datasheet floating around under the name
"TCITSMCN40GGPMPLLA1_guide" which has more information about the PLL's
internals.
> + writel(val, regs + K210_SYSCTL_PLL1);
> +
> + k210_clear_bits(PLL_BYPASS, regs + K210_SYSCTL_PLL1);
> + k210_set_bits(PLL_PWR, regs + K210_SYSCTL_PLL1);
> +
> + /*
> + * Reset the pll. The magic NOPs come from the Kendryte reference SDK.
> + */
> + k210_clear_bits(PLL_RESET, regs + K210_SYSCTL_PLL1);
> + k210_set_bits(PLL_RESET, regs + K210_SYSCTL_PLL1);
> + nop();
> + nop();
> + k210_clear_bits(PLL_RESET, regs + K210_SYSCTL_PLL1);
> +
> + for (;;) {
> + val = readl(regs + K210_SYSCTL_PLL_LOCK);
> + if (val & PLL1_LOCK2)
> + break;
> + writel(val | PLL1_SLIP_CLEAR, regs + K210_SYSCTL_PLL_LOCK);
> + }
> +
> + k210_set_bits(PLL_OUT_EN, regs + K210_SYSCTL_PLL1);
> +}
> +
> +static unsigned long k210_sysctl_clk_recalc_rate(struct clk_hw *hw,
> + unsigned long parent_rate)
> +{
> + struct k210_sysctl *s = container_of(hw, struct k210_sysctl, hw);
> + u32 clksel0, pll0;
> + u64 pll0_freq, clkr0, clkf0, clkod0;
> +
> + /*
> + * If the clock selector is not set, use the base frequency.
> + * Otherwise, use PLL0 frequency with a frequency divisor.
> + */
> + clksel0 = readl(s->regs + K210_SYSCTL_CLKSEL0);
> + if (!(clksel0 & CLKSEL_ACLK))
> + return K210_SYSCTL_CLK0_FREQ;
> +
> + /*
> + * Get PLL0 frequency:
> + * freq = base frequency * clkf0 / (clkr0 * clkod0)
> + */
> + pll0 = readl(s->regs + K210_SYSCTL_PLL0);
> + clkr0 = 1 + (pll0 & 0x0000000f);
> + clkf0 = 1 + ((pll0 & 0x000003f0) >> 4);
> + clkod0 = 1 + ((pll0 & 0x00003c00) >> 10);
Can you do this with FIELD_GET and GENMASK instead?
> + pll0_freq = clkf0 * K210_SYSCTL_CLK0_FREQ / (clkr0 * clkod0);
> +
> + /* Get the frequency divisor from the clock selector */
> + return pll0_freq / (2ULL << ((clksel0 & 0x00000006) >> 1));
Same thing here.
> +}
> +
> +static const struct clk_ops k210_sysctl_clk_ops = {
> + .recalc_rate = k210_sysctl_clk_recalc_rate,
> +};
> +
> +static const struct clk_init_data k210_clk_init_data = {
> + .name = "k210-sysctl-pll1",
> + .ops = &k210_sysctl_clk_ops,
> +};
> +
> +static int k210_sysctl_probe(struct platform_device *pdev)
> +{
> + struct k210_sysctl *s;
> + int error;
> +
> + pr_info("Kendryte K210 SoC sysctl\n");
> +
> + s = devm_kzalloc(&pdev->dev, sizeof(*s), GFP_KERNEL);
> + if (!s)
> + return -ENOMEM;
> +
> + s->regs = devm_ioremap_resource(&pdev->dev,
> + platform_get_resource(pdev, IORESOURCE_MEM, 0));
> + if (IS_ERR(s->regs))
> + return PTR_ERR(s->regs);
> +
> + s->hw.init = &k210_clk_init_data;
> + error = devm_clk_hw_register(&pdev->dev, &s->hw);
> + if (error) {
> + dev_err(&pdev->dev, "failed to register clk");
> + return error;
> + }
> +
> + error = devm_of_clk_add_hw_provider(&pdev->dev, of_clk_hw_simple_get,
> + &s->hw);
> + if (error) {
> + dev_err(&pdev->dev, "adding clk provider failed\n");
> + return error;
> + }
> +
> + return 0;
> +}
> +
> +static const struct of_device_id k210_sysctl_of_match[] = {
> + { .compatible = "kendryte,k210-sysctl", },
> + {}
> +};
> +
> +static struct platform_driver k210_sysctl_driver = {
> + .driver = {
> + .name = "k210-sysctl",
> + .of_match_table = k210_sysctl_of_match,
> + },
> + .probe = k210_sysctl_probe,
> +};
> +
> +static int __init k210_sysctl_init(void)
> +{
> + return platform_driver_register(&k210_sysctl_driver);
> +}
> +core_initcall(k210_sysctl_init);
> +
> +/*
> + * This needs to be called very early during initialization, given that
> + * PLL1 needs to be enabled to be able to use all SRAM.
> + */
> +static void __init k210_soc_early_init(const void *fdt)
> +{
> + void __iomem *regs;
> +
> + regs = ioremap(K210_SYSCTL_SYSCTL_BASE_ADDR, 0x1000);
> + if (!regs)
> + panic("K210 sysctl ioremap");
> +
> + /* Enable PLL1 to make the KPU SRAM useable */
> + k210_pll1_enable(regs);
> +
> + k210_set_bits(PLL_OUT_EN, regs + K210_SYSCTL_PLL0);
> +
> + k210_set_bits(CLKEN_CPU | CLKEN_SRAM0 | CLKEN_SRAM1,
> + regs + K210_SYSCTL_CLKEN_CENT);
> + k210_set_bits(CLKEN_ROM | CLKEN_TIMER0 | CLKEN_RTC,
> + regs + K210_SYSCTL_CLKEN_PERI);
> +
> + k210_set_bits(CLKSEL_ACLK, regs + K210_SYSCTL_CLKSEL0);
> +
> + iounmap(regs);
> +}
> +SOC_EARLY_INIT_DECLARE("kendryte,k210", k210_soc_early_init);
--Sean
^ permalink raw reply
* [RFC PATCH] iommu/iova: Support limiting IOVA alignment
From: Liam Mark @ 2020-02-14 20:30 UTC (permalink / raw)
To: Joerg Roedel
Cc: kernel-team, Isaac J. Manjarres, Pratik Patel, linux-kernel,
iommu
When the IOVA framework applies IOVA alignment it aligns all
IOVAs to the smallest PAGE_SIZE order which is greater than or
equal to the requested IOVA size.
We support use cases that requires large buffers (> 64 MB in
size) to be allocated and mapped in their stage 1 page tables.
However, with this alignment scheme we find ourselves running
out of IOVA space for 32 bit devices, so we are proposing this
config, along the similar vein as CONFIG_CMA_ALIGNMENT for CMA
allocations.
Add CONFIG_IOMMU_LIMIT_IOVA_ALIGNMENT to limit the alignment of
IOVAs to some desired PAGE_SIZE order, specified by
CONFIG_IOMMU_IOVA_ALIGNMENT. This helps reduce the impact of
fragmentation caused by the current IOVA alignment scheme, and
gives better IOVA space utilization.
Signed-off-by: Liam Mark <lmark@codeaurora.org>
---
drivers/iommu/Kconfig | 31 +++++++++++++++++++++++++++++++
drivers/iommu/iova.c | 20 +++++++++++++++++++-
2 files changed, 50 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index d2fade984999..9684a153cc72 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -3,6 +3,37 @@
config IOMMU_IOVA
tristate
+if IOMMU_IOVA
+
+config IOMMU_LIMIT_IOVA_ALIGNMENT
+ bool "Limit IOVA alignment"
+ help
+ When the IOVA framework applies IOVA alignment it aligns all
+ IOVAs to the smallest PAGE_SIZE order which is greater than or
+ equal to the requested IOVA size. This works fine for sizes up
+ to several MiB, but for larger sizes it results in address
+ space wastage and fragmentation. For example drivers with a 4
+ GiB IOVA space might run out of IOVA space when allocating
+ buffers great than 64 MiB.
+
+ Enable this option to impose a limit on the alignment of IOVAs.
+
+ If unsure, say N.
+
+config IOMMU_IOVA_ALIGNMENT
+ int "Maximum PAGE_SIZE order of alignment for IOVAs"
+ depends on IOMMU_LIMIT_IOVA_ALIGNMENT
+ range 4 9
+ default 9
+ help
+ With this parameter you can specify the maximum PAGE_SIZE order for
+ IOVAs. Larger IOVAs will be aligned only to this specified order.
+ The order is expressed a power of two multiplied by the PAGE_SIZE.
+
+ If unsure, leave the default value "9".
+
+endif
+
# The IOASID library may also be used by non-IOMMU_API users
config IOASID
tristate
diff --git a/drivers/iommu/iova.c b/drivers/iommu/iova.c
index 0e6a9536eca6..259884c8dbd1 100644
--- a/drivers/iommu/iova.c
+++ b/drivers/iommu/iova.c
@@ -177,6 +177,24 @@ int init_iova_flush_queue(struct iova_domain *iovad,
rb_insert_color(&iova->node, root);
}
+#ifdef CONFIG_IOMMU_LIMIT_IOVA_ALIGNMENT
+static unsigned long limit_align_shift(struct iova_domain *iovad,
+ unsigned long shift)
+{
+ unsigned long max_align_shift;
+
+ max_align_shift = CONFIG_IOMMU_IOVA_ALIGNMENT + PAGE_SHIFT
+ - iova_shift(iovad);
+ return min_t(unsigned long, max_align_shift, shift);
+}
+#else
+static unsigned long limit_align_shift(struct iova_domain *iovad,
+ unsigned long shift)
+{
+ return shift;
+}
+#endif
+
static int __alloc_and_insert_iova_range(struct iova_domain *iovad,
unsigned long size, unsigned long limit_pfn,
struct iova *new, bool size_aligned)
@@ -188,7 +206,7 @@ static int __alloc_and_insert_iova_range(struct iova_domain *iovad,
unsigned long align_mask = ~0UL;
if (size_aligned)
- align_mask <<= fls_long(size - 1);
+ align_mask <<= limit_align_shift(iovad, fls_long(size - 1));
/* Walk the tree backwards */
spin_lock_irqsave(&iovad->iova_rbtree_lock, flags);
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply related
* Re: Debugging errors with Dell XPS 9560 TPM
From: James Bottomley @ 2020-02-14 20:29 UTC (permalink / raw)
To: Alex Guzman, linux-integrity
In-Reply-To: <CAJ7-PMbJ5fiQAj-5QAzAcFW0eMNkxpQSs=r_wUEfED33XZAPDg@mail.gmail.com>
On Fri, 2020-02-14 at 10:32 -0800, Alex Guzman wrote:
> Looks like someone had a look on the bug tracker
> (https://bugzilla.kernel.org/show_bug.cgi?id=206275#c6)
> and they figure it's definitely a regression in the kernel and should
> be reverted or rectified. They advised me to come ping here once
> more.
Reading the bugzilla, I don't get *what* needs to be reverted. The
commit 4d6ebc4c4950595414722dfadd0b361f5a05d37e isn't present in
upstream, so what kernel is it present in, or what is the full commit
message so we can find the upstream commit?
James
> - Alex
>
> On Sat, Feb 1, 2020 at 4:19 PM Alex Guzman <alex@guzman.io> wrote:
> >
> > Hey there! I reported a bug on the bug tracker a bit ago but
> > haven't
> > seen any movement, so I figured I'd drop in here. My XPS 9560 has
> > been
> > having issues with its TPM, and all commands will fail with error 1
> > when operating on the TPM device. I managed to bisect it back to
> > commit 4d6ebc4c4950595414722dfadd0b361f5a05d37e (tpm: fix invalid
> > locking in NONBLOCKING mode) though it began failing with error 14
> > (bad address) at that point.
> >
> > I reported the bug at
> > https://bugzilla.kernel.org/show_bug.cgi?id=206275 and attached
> > some
> > dmesg logs from boot there. Does anyone have any suggestions for
> > additional debugging or such to figure out what's happening here?
> >
> > - Alex
>
>
^ permalink raw reply
* Re: [PATCH 09/11] drm, cgroup: Introduce lgpu as DRM cgroup resource
From: Kenny Ho @ 2020-02-14 20:28 UTC (permalink / raw)
To: Tejun Heo
Cc: juan.zuniga-anaya, Daniel Vetter, Kenny Ho, Kuehling, Felix,
jsparks, nirmoy.das, Maling list - DRI developers, lkaplan,
Greathouse, Joseph, amd-gfx mailing list, Jason Ekstrand,
Johannes Weiner, Alex Deucher, cgroups, Christian König,
damon.mcdougall
In-Reply-To: <20200214191754.GA218629@mtj.thefacebook.com>
Hi Tejun,
On Fri, Feb 14, 2020 at 2:17 PM Tejun Heo <tj@kernel.org> wrote:
>
> I have to agree with Daniel here. My apologies if I weren't clear
> enough. Here's one interface I can think of:
>
> * compute weight: The same format as io.weight. Proportional control
> of gpu compute.
>
> * memory low: Please see how the system memory.low behaves. For gpus,
> it'll need per-device entries.
>
> Note that for both, there one number to configure and conceptually
> it's pretty clear to everybody what that number means, which is not to
> say that it's clear to implement but it's much better to deal with
> that on this side of the interface than the other.
Can you elaborate, per your understanding, how the lgpu weight
attribute differ from the io.weight you suggested? Is it merely a
formatting/naming issue or is it the implementation details that you
find troubling? From my perspective, the weight attribute implements
as you suggested back in RFCv4 (proportional control on top of a unit
- either physical or time unit.)
Perhaps more explicit questions would help me understand what you
mean. If I remove the 'list' and 'count' attributes leaving just
weight, is that satisfactory? Are you saying the idea of affinity or
named-resource is banned from cgroup entirely (even though it exists
in the form of cpuset already and users are interested in having such
options [i.e. userspace OpenCL] when needed?)
To be clear, I am not saying no proportional control. I am saying
give the user the options, which is what has been implemented.
> cc'ing Johannes. Do you have anything on mind regarding how gpu memory
> configuration should look like? e.g. should it go w/ weights rather
> than absoulte units (I don't think so given that it'll most likely
> need limits at some point too but still and there are benefits from
> staying consistent with system memory).
>
> Also, a rather trivial high level question. Is drm a good controller
> name given that other controller names are like cpu, memory, io?
There was a discussion about naming early in the RFC (I believe
RFCv2), the consensuses then was to use drmcg to align with the drm
subsystem. I have no problem renaming it to gpucg or something
similar if that is the last thing that's blocking acceptance. For
now, I would like to get some clarity on the implementation before
having more code churn.
Regards,
Kenny
> Thanks.
>
> --
> tejun
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
^ permalink raw reply
* Re: [PATCH 09/11] drm, cgroup: Introduce lgpu as DRM cgroup resource
From: Kenny Ho @ 2020-02-14 20:28 UTC (permalink / raw)
To: Tejun Heo
Cc: juan.zuniga-anaya, Kenny Ho, Kuehling, Felix, jsparks, nirmoy.das,
Maling list - DRI developers, lkaplan, Greathouse, Joseph,
amd-gfx mailing list, Jason Ekstrand, Johannes Weiner,
Alex Deucher, cgroups, Christian König, damon.mcdougall
In-Reply-To: <20200214191754.GA218629@mtj.thefacebook.com>
Hi Tejun,
On Fri, Feb 14, 2020 at 2:17 PM Tejun Heo <tj@kernel.org> wrote:
>
> I have to agree with Daniel here. My apologies if I weren't clear
> enough. Here's one interface I can think of:
>
> * compute weight: The same format as io.weight. Proportional control
> of gpu compute.
>
> * memory low: Please see how the system memory.low behaves. For gpus,
> it'll need per-device entries.
>
> Note that for both, there one number to configure and conceptually
> it's pretty clear to everybody what that number means, which is not to
> say that it's clear to implement but it's much better to deal with
> that on this side of the interface than the other.
Can you elaborate, per your understanding, how the lgpu weight
attribute differ from the io.weight you suggested? Is it merely a
formatting/naming issue or is it the implementation details that you
find troubling? From my perspective, the weight attribute implements
as you suggested back in RFCv4 (proportional control on top of a unit
- either physical or time unit.)
Perhaps more explicit questions would help me understand what you
mean. If I remove the 'list' and 'count' attributes leaving just
weight, is that satisfactory? Are you saying the idea of affinity or
named-resource is banned from cgroup entirely (even though it exists
in the form of cpuset already and users are interested in having such
options [i.e. userspace OpenCL] when needed?)
To be clear, I am not saying no proportional control. I am saying
give the user the options, which is what has been implemented.
> cc'ing Johannes. Do you have anything on mind regarding how gpu memory
> configuration should look like? e.g. should it go w/ weights rather
> than absoulte units (I don't think so given that it'll most likely
> need limits at some point too but still and there are benefits from
> staying consistent with system memory).
>
> Also, a rather trivial high level question. Is drm a good controller
> name given that other controller names are like cpu, memory, io?
There was a discussion about naming early in the RFC (I believe
RFCv2), the consensuses then was to use drmcg to align with the drm
subsystem. I have no problem renaming it to gpucg or something
similar if that is the last thing that's blocking acceptance. For
now, I would like to get some clarity on the implementation before
having more code churn.
Regards,
Kenny
> Thanks.
>
> --
> tejun
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH 09/11] drm, cgroup: Introduce lgpu as DRM cgroup resource
From: Kenny Ho @ 2020-02-14 20:28 UTC (permalink / raw)
To: Tejun Heo
Cc: Daniel Vetter, Jason Ekstrand, Kenny Ho,
cgroups-u79uwXL29TY76Z2rM5mHXA, Maling list - DRI developers,
amd-gfx mailing list, Alex Deucher, Christian König,
Kuehling, Felix, Greathouse, Joseph, jsparks-WVYJKLFxKCc,
lkaplan-WVYJKLFxKCc, nirmoy.das-5C7GfCeVMHo,
damon.mcdougall-5C7GfCeVMHo, juan.zuniga-anaya-5C7GfCeVMHo,
Johannes Weiner
In-Reply-To: <20200214191754.GA218629-146+VewaZzwNjtGbbfXrCEEOCMrvLtNR@public.gmane.org>
Hi Tejun,
On Fri, Feb 14, 2020 at 2:17 PM Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
>
> I have to agree with Daniel here. My apologies if I weren't clear
> enough. Here's one interface I can think of:
>
> * compute weight: The same format as io.weight. Proportional control
> of gpu compute.
>
> * memory low: Please see how the system memory.low behaves. For gpus,
> it'll need per-device entries.
>
> Note that for both, there one number to configure and conceptually
> it's pretty clear to everybody what that number means, which is not to
> say that it's clear to implement but it's much better to deal with
> that on this side of the interface than the other.
Can you elaborate, per your understanding, how the lgpu weight
attribute differ from the io.weight you suggested? Is it merely a
formatting/naming issue or is it the implementation details that you
find troubling? From my perspective, the weight attribute implements
as you suggested back in RFCv4 (proportional control on top of a unit
- either physical or time unit.)
Perhaps more explicit questions would help me understand what you
mean. If I remove the 'list' and 'count' attributes leaving just
weight, is that satisfactory? Are you saying the idea of affinity or
named-resource is banned from cgroup entirely (even though it exists
in the form of cpuset already and users are interested in having such
options [i.e. userspace OpenCL] when needed?)
To be clear, I am not saying no proportional control. I am saying
give the user the options, which is what has been implemented.
> cc'ing Johannes. Do you have anything on mind regarding how gpu memory
> configuration should look like? e.g. should it go w/ weights rather
> than absoulte units (I don't think so given that it'll most likely
> need limits at some point too but still and there are benefits from
> staying consistent with system memory).
>
> Also, a rather trivial high level question. Is drm a good controller
> name given that other controller names are like cpu, memory, io?
There was a discussion about naming early in the RFC (I believe
RFCv2), the consensuses then was to use drmcg to align with the drm
subsystem. I have no problem renaming it to gpucg or something
similar if that is the last thing that's blocking acceptance. For
now, I would like to get some clarity on the implementation before
having more code churn.
Regards,
Kenny
> Thanks.
>
> --
> tejun
^ permalink raw reply
* Re: [PATCH] sched/isolation: Allow "isolcpus=" to skip unknown sub-parameters
From: Thomas Gleixner @ 2020-02-14 20:28 UTC (permalink / raw)
To: Peter Xu, linux-kernel
Cc: Ming Lei, Ingo Molnar, Peter Zijlstra, Juri Lelli,
Luiz Capitulino
In-Reply-To: <20200214194008.GA1193332@xz-x1>
Peter Xu <peterx@redhat.com> writes:
> On Tue, Feb 04, 2020 at 11:16:39AM -0500, Peter Xu wrote:
>> The "isolcpus=" parameter allows sub-parameters to exist before the
>> cpulist is specified, and if it sees unknown sub-parameters the whole
>> parameter will be ignored. This design is incompatible with itself
>> when we add more sub-parameters to "isolcpus=", because the old
>> kernels will not recognize the new "isolcpus=" sub-parameters, then it
>> will invalidate the whole parameter so the CPU isolation will not
>> really take effect if we start to use the new sub-parameters while
>> later we reboot into an old kernel. Instead we will see this when
>> booting the old kernel:
>>
>> isolcpus: Error, unknown flag
>>
>> The better and compatible way is to allow "isolcpus=" to skip unknown
>> sub-parameters, so that even if we add new sub-parameters to it the
>> old kernel will still be able to behave as usual even if with the new
>> sub-parameter is specified.
>>
>> Ideally this patch should be there when we introduce the first
>> sub-parameter for "isolcpus=", so it's already a bit late. However
>> late is better than nothing.
>
> Ping - Hi, Thomas, do you have any further comment on this patch?
Fine with me.
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
^ permalink raw reply
* Re: [PATCH v2 4/4] libnvdimm/region: Introduce an 'align' attribute
From: Jeff Moyer @ 2020-02-14 20:19 UTC (permalink / raw)
To: Dan Williams
Cc: Aneesh Kumar K.V, vishal.l.verma, linuxppc-dev, linux-kernel,
linux-nvdimm
In-Reply-To: <158155491952.3343782.4541070487858304628.stgit@dwillia2-desk3.amr.corp.intel.com>
Dan Williams <dan.j.williams@intel.com> writes:
> The align attribute applies an alignment constraint for namespace
> creation in a region. Whereas the 'align' attribute of a namespace
> applied alignment padding via an info block, the 'align' attribute
> applies alignment constraints to the free space allocation.
>
> The default for 'align' is the maximum known memremap_compat_align()
> across all archs (16MiB from PowerPC at time of writing) multiplied by
> the number of interleave ways if there is blk-aliasing. The minimum is
> PAGE_SIZE and allows for the creation of cross-arch incompatible
> namespaces, just as previous kernels allowed, but the expectation is
> cross-arch and mode-independent compatibility by default.
>
> The regression risk with this change is limited to cases that were
> dependent on the ability to create unaligned namespaces, *and* for some
> reason are unable to opt-out of aligned namespaces by writing to
> 'regionX/align'. If such a scenario arises the default can be flipped
> from opt-out to opt-in of compat-aligned namespace creation, but that is
> a last resort. The kernel will otherwise continue to support existing
> defined misaligned namespaces.
>
> Unfortunately this change needs to touch several parts of the
> implementation at once:
>
> - region/available_size: expand busy extents to current align
> - region/max_available_extent: expand busy extents to current align
> - namespace/size: trim free space to current align
>
> ...to keep the free space accounting conforming to the dynamic align
> setting.
>
> Reported-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
> Reported-by: Jeff Moyer <jmoyer@redhat.com>
> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
> Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
> Link: https://lore.kernel.org/r/158041478371.3889308.14542630147672668068.stgit@dwillia2-desk3.amr.corp.intel.com
> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
This looks good to me.
Reviewed-by: Jeff Moyer <jmoyer@redhat.com>
^ permalink raw reply
* Re: [PATCH v2 12/21] target/arm: Read debug-related ID registers from KVM
From: Richard Henderson @ 2020-02-14 20:27 UTC (permalink / raw)
To: Peter Maydell, qemu-arm, qemu-devel
Cc: Eric Auger, Aaron Lindsay, Philippe Mathieu-Daudé
In-Reply-To: <20200214175116.9164-13-peter.maydell@linaro.org>
On 2/14/20 9:51 AM, Peter Maydell wrote:
> + /*
> + * DBGDIDR is a bit complicated because the kernel doesn't
> + * provide an accessor for it in 64-bit mode, which is what this
> + * scratch VM is in, and there's no architected "64-bit sysreg
> + * which reads the same as the 32-bit register" the way there is
> + * for other ID registers. Instead we synthesize a value from the
> + * AArch64 ID_AA64DFR0, the same way the kernel code in
> + * arch/arm64/kvm/sys_regs.c:trap_dbgidr() does.
> + * We only do this if the CPU supports AArch32 at EL1.
> + */
> + if (FIELD_EX32(ahcf->isar.id_aa64pfr0, ID_AA64PFR0, EL1) >= 2) {
> + int wrps = FIELD_EX64(ahcf->isar.id_aa64dfr0, ID_AA64DFR0, WRPS);
> + int brps = FIELD_EX64(ahcf->isar.id_aa64dfr0, ID_AA64DFR0, BRPS);
> + int ctx_cmps =
> + FIELD_EX64(ahcf->isar.id_aa64dfr0, ID_AA64DFR0, CTX_CMPS);
> + int version = 6; /* ARMv8 debug architecture */
> + bool has_el3 =
> + !!FIELD_EX32(ahcf->isar.id_aa64pfr0, ID_AA64PFR0, EL3);
> + uint32_t dbgdidr = 0;
> +
> + dbgdidr = FIELD_DP32(dbgdidr, DBGDIDR, WRPS, wrps);
> + dbgdidr = FIELD_DP32(dbgdidr, DBGDIDR, BRPS, brps);
> + dbgdidr = FIELD_DP32(dbgdidr, DBGDIDR, CTX_CMPS, ctx_cmps);
> + dbgdidr = FIELD_DP32(dbgdidr, DBGDIDR, VERSION, version);
> + dbgdidr = FIELD_DP32(dbgdidr, DBGDIDR, NSUHD_IMP, has_el3);
> + dbgdidr = FIELD_DP32(dbgdidr, DBGDIDR, SE_IMP, has_el3);
> + dbgdidr |= (1 << 16); /* RES1 bit */
I see the RES1 bit as 15.
Otherwise,
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
r~
^ permalink raw reply
* Re: [PATCH] mm: vmscan: replace open codings to NUMA_NO_NODE
From: David Rientjes @ 2020-02-14 20:27 UTC (permalink / raw)
To: Yang Shi; +Cc: minchan, anshuman.khandual, akpm, linux-mm, linux-kernel
In-Reply-To: <1581568298-45317-1-git-send-email-yang.shi@linux.alibaba.com>
On Thu, 13 Feb 2020, Yang Shi wrote:
> The commit 98fa15f34cb3 ("mm: replace all open encodings for
> NUMA_NO_NODE") did the replacement across the kernel tree, but we got
> some more in vmscan.c since then.
>
> Cc: Minchan Kim <minchan@kernel.org>
> Cc: Anshuman Khandual <anshuman.khandual@arm.com>
> Signed-off-by: Yang Shi <yang.shi@linux.alibaba.com>
Acked-by: David Rientjes <rientjes@google.com>
^ permalink raw reply
* [igt-dev] ✓ Fi.CI.BAT: success for series starting with [i-g-t,1/4] i915/gem_ctx_engines: Exercise 0 engines[]
From: Patchwork @ 2020-02-14 20:26 UTC (permalink / raw)
To: Chris Wilson; +Cc: igt-dev
In-Reply-To: <20200214194016.4054376-1-chris@chris-wilson.co.uk>
== Series Details ==
Series: series starting with [i-g-t,1/4] i915/gem_ctx_engines: Exercise 0 engines[]
URL : https://patchwork.freedesktop.org/series/73485/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7942 -> IGTPW_4157
====================================================
Summary
-------
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4157/index.html
Known issues
------------
Here are the changes found in IGTPW_4157 that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@gem_close_race@basic-threads:
- fi-hsw-peppy: [PASS][1] -> [INCOMPLETE][2] ([i915#694] / [i915#816])
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7942/fi-hsw-peppy/igt@gem_close_race@basic-threads.html
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4157/fi-hsw-peppy/igt@gem_close_race@basic-threads.html
- fi-byt-n2820: [PASS][3] -> [INCOMPLETE][4] ([i915#45])
[3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7942/fi-byt-n2820/igt@gem_close_race@basic-threads.html
[4]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4157/fi-byt-n2820/igt@gem_close_race@basic-threads.html
* igt@i915_selftest@live_gem_contexts:
- fi-cml-s: [PASS][5] -> [DMESG-FAIL][6] ([i915#877])
[5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7942/fi-cml-s/igt@i915_selftest@live_gem_contexts.html
[6]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4157/fi-cml-s/igt@i915_selftest@live_gem_contexts.html
#### Possible fixes ####
* igt@i915_selftest@live_gem_contexts:
- fi-cfl-8700k: [INCOMPLETE][7] ([i915#424]) -> [PASS][8]
[7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7942/fi-cfl-8700k/igt@i915_selftest@live_gem_contexts.html
[8]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4157/fi-cfl-8700k/igt@i915_selftest@live_gem_contexts.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#424]: https://gitlab.freedesktop.org/drm/intel/issues/424
[i915#45]: https://gitlab.freedesktop.org/drm/intel/issues/45
[i915#694]: https://gitlab.freedesktop.org/drm/intel/issues/694
[i915#816]: https://gitlab.freedesktop.org/drm/intel/issues/816
[i915#877]: https://gitlab.freedesktop.org/drm/intel/issues/877
[i915#937]: https://gitlab.freedesktop.org/drm/intel/issues/937
Participating hosts (47 -> 45)
------------------------------
Additional (4): fi-bsw-kefka fi-blb-e6850 fi-cfl-8109u fi-ilk-650
Missing (6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-bdw-samus
Build changes
-------------
* CI: CI-20190529 -> None
* IGT: IGT_5442 -> IGTPW_4157
CI-20190529: 20190529
CI_DRM_7942: f4805f5a516d0a107438ff0f236c9f4187434819 @ git://anongit.freedesktop.org/gfx-ci/linux
IGTPW_4157: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4157/index.html
IGT_5442: 3f6080996885b997685f08ecb8b416b2dc485290 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
== Testlist changes ==
+igt@gem_ctx_engines@libapi
+igt@gem_ctx_engines@none
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4157/index.html
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev
^ permalink raw reply
* Re: [PATCH] x86/mce/amd: Fix kobject lifetime
From: Thomas Gleixner @ 2020-02-14 20:26 UTC (permalink / raw)
To: Borislav Petkov, Greg KH; +Cc: stable, X86 ML, Yazen Ghannam, LKML
In-Reply-To: <20200214201143.GQ13395@zn.tnic>
Borislav Petkov <bp@alien8.de> writes:
> On Fri, Feb 14, 2020 at 07:17:27AM -0800, Greg KH wrote:
>> Does not bother me at all, it's fine to see stuff come by that will end
>> up in future trees, it's not noise at all. So no need to suppress
>> stable@vger if you don't want to.
>
> Ok, but what about your formletter which you send to people explaining
> this is not how you should send a patch to stable?
>
> Like this, for example:
>
> https://lkml.kernel.org/r/20200116100925.GA157179@kroah.com
This once Cc'ed stable but lacked a Cc: stable tag in the changelog.
Thanks,
tglx
^ permalink raw reply
* Re: [PATCH 2/3] Teach SELinux about anonymous inodes
From: Stephen Smalley @ 2020-02-14 20:24 UTC (permalink / raw)
To: Daniel Colascione
Cc: Tim Murray, SElinux list, LSM List, Linux FS Devel, linux-kernel,
kvm, Al Viro, paul, Nick Kralevich, Lokesh Gidra,
Jeffrey Vander Stoep
In-Reply-To: <97603935-9f6b-ccf4-4229-87f26380c3db@tycho.nsa.gov>
On 2/14/20 1:08 PM, Stephen Smalley wrote:
> On 2/14/20 1:02 PM, Stephen Smalley wrote:
>> It shouldn't fire for non-anon inodes because on a (non-anon) file
>> creation, security_transition_sid() is passed the parent directory SID
>> as the second argument and we only assign task SIDs to /proc/pid
>> directories, which don't support (userspace) file creation anyway.
>>
>> However, in the absence of a matching type_transition rule, we'll end
>> up defaulting to the task SID on the anon inode, and without a
>> separate class we won't be able to distinguish it from a /proc/pid
>> inode. So that might justify a separate anoninode or similar class.
>>
>> This however reminded me that for the context_inode case, we not only
>> want to inherit the SID but also the sclass from the context_inode.
>> That is so that anon inodes created via device node ioctls inherit the
>> same SID/class pair as the device node and a single allowx rule can
>> govern all ioctl commands on that device.
>
> At least that's the way our patch worked with the /dev/kvm example.
> However, if we are introducing a separate anoninode class for the
> type_transition case, maybe we should apply that to all anon inodes
> regardless of how they are labeled (based on context_inode or
> transition) and then we'd need to write two allowx rules, one for ioctls
> on the original device node and one for those on anon inodes created
> from it. Not sure how Android wants to handle that as the original
> developer and primary user of SELinux ioctl whitelisting.
I would tentatively argue for inheriting both sclass and SID from the
context_inode for the sake of sane policy writing. In the userfaultfd
case, that will still end up using the new SECCLASS_ANONINODE or
whatever since the sclass will be initially set to that value for the
transition SID case and then inherited on fork. But for /dev/kvm, it
would be the class from the /dev/kvm inode, i.e. SECCLASS_CHR_FILE.
^ permalink raw reply
* [igt-dev] ✗ Fi.CI.IGT: failure for benchmarks/gem_wsim: Avoid labs(unsigned long)
From: Patchwork @ 2020-02-14 20:23 UTC (permalink / raw)
To: Ville Syrjala; +Cc: igt-dev
In-Reply-To: <20200212171732.2187-1-ville.syrjala@linux.intel.com>
== Series Details ==
Series: benchmarks/gem_wsim: Avoid labs(unsigned long)
URL : https://patchwork.freedesktop.org/series/73375/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7924_full -> IGTPW_4138_full
====================================================
Summary
-------
**FAILURE**
Serious unknown changes coming with IGTPW_4138_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in IGTPW_4138_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4138/index.html
Possible new issues
-------------------
Here are the unknown changes that may have been introduced in IGTPW_4138_full:
### IGT changes ###
#### Possible regressions ####
* igt@kms_color@pipe-a-legacy-gamma:
- shard-tglb: [PASS][1] -> [FAIL][2]
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7924/shard-tglb7/igt@kms_color@pipe-a-legacy-gamma.html
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4138/shard-tglb6/igt@kms_color@pipe-a-legacy-gamma.html
Known issues
------------
Here are the changes found in IGTPW_4138_full that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@gem_exec_parallel@vcs1-fds:
- shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#112080]) +16 similar issues
[3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7924/shard-iclb4/igt@gem_exec_parallel@vcs1-fds.html
[4]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4138/shard-iclb5/igt@gem_exec_parallel@vcs1-fds.html
* igt@gem_exec_schedule@pi-common-bsd:
- shard-iclb: [PASS][5] -> [SKIP][6] ([i915#677]) +1 similar issue
[5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7924/shard-iclb3/igt@gem_exec_schedule@pi-common-bsd.html
[6]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4138/shard-iclb4/igt@gem_exec_schedule@pi-common-bsd.html
* igt@gem_exec_schedule@preemptive-hang-bsd:
- shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#112146]) +3 similar issues
[7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7924/shard-iclb8/igt@gem_exec_schedule@preemptive-hang-bsd.html
[8]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4138/shard-iclb4/igt@gem_exec_schedule@preemptive-hang-bsd.html
* igt@gem_mmap_gtt@basic-copy:
- shard-snb: [PASS][9] -> [DMESG-WARN][10] ([i915#478])
[9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7924/shard-snb6/igt@gem_mmap_gtt@basic-copy.html
[10]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4138/shard-snb5/igt@gem_mmap_gtt@basic-copy.html
* igt@gem_ppgtt@flink-and-close-vma-leak:
- shard-tglb: [PASS][11] -> [FAIL][12] ([i915#644])
[11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7924/shard-tglb2/igt@gem_ppgtt@flink-and-close-vma-leak.html
[12]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4138/shard-tglb8/igt@gem_ppgtt@flink-and-close-vma-leak.html
* igt@gem_softpin@noreloc-s3:
- shard-snb: [PASS][13] -> [DMESG-WARN][14] ([i915#42])
[13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7924/shard-snb5/igt@gem_softpin@noreloc-s3.html
[14]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4138/shard-snb2/igt@gem_softpin@noreloc-s3.html
* igt@gem_userptr_blits@sync-unmap-cycles:
- shard-snb: [PASS][15] -> [DMESG-WARN][16] ([fdo#111870] / [i915#478])
[15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7924/shard-snb4/igt@gem_userptr_blits@sync-unmap-cycles.html
[16]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4138/shard-snb2/igt@gem_userptr_blits@sync-unmap-cycles.html
* igt@gem_workarounds@suspend-resume-fd:
- shard-kbl: [PASS][17] -> [DMESG-WARN][18] ([i915#180]) +2 similar issues
[17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7924/shard-kbl1/igt@gem_workarounds@suspend-resume-fd.html
[18]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4138/shard-kbl4/igt@gem_workarounds@suspend-resume-fd.html
* igt@i915_pm_dc@dc5-dpms:
- shard-iclb: [PASS][19] -> [FAIL][20] ([i915#447])
[19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7924/shard-iclb5/igt@i915_pm_dc@dc5-dpms.html
[20]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4138/shard-iclb3/igt@i915_pm_dc@dc5-dpms.html
* igt@kms_cursor_crc@pipe-a-cursor-128x128-random:
- shard-tglb: [PASS][21] -> [FAIL][22] ([fdo#111703])
[21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7924/shard-tglb2/igt@kms_cursor_crc@pipe-a-cursor-128x128-random.html
[22]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4138/shard-tglb8/igt@kms_cursor_crc@pipe-a-cursor-128x128-random.html
* igt@kms_cursor_crc@pipe-c-cursor-64x21-offscreen:
- shard-apl: [PASS][23] -> [FAIL][24] ([i915#54])
[23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7924/shard-apl6/igt@kms_cursor_crc@pipe-c-cursor-64x21-offscreen.html
[24]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4138/shard-apl2/igt@kms_cursor_crc@pipe-c-cursor-64x21-offscreen.html
* igt@kms_cursor_crc@pipe-c-cursor-suspend:
- shard-apl: [PASS][25] -> [DMESG-WARN][26] ([i915#180]) +3 similar issues
[25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7924/shard-apl1/igt@kms_cursor_crc@pipe-c-cursor-suspend.html
[26]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4138/shard-apl8/igt@kms_cursor_crc@pipe-c-cursor-suspend.html
* igt@kms_draw_crc@draw-method-xrgb2101010-pwrite-ytiled:
- shard-tglb: [PASS][27] -> [FAIL][28] ([i915#559]) +2 similar issues
[27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7924/shard-tglb8/igt@kms_draw_crc@draw-method-xrgb2101010-pwrite-ytiled.html
[28]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4138/shard-tglb5/igt@kms_draw_crc@draw-method-xrgb2101010-pwrite-ytiled.html
* igt@kms_flip@basic-flip-vs-dpms:
- shard-hsw: [PASS][29] -> [INCOMPLETE][30] ([CI#80] / [i915#61])
[29]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7924/shard-hsw7/igt@kms_flip@basic-flip-vs-dpms.html
[30]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4138/shard-hsw5/igt@kms_flip@basic-flip-vs-dpms.html
* igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-spr-indfb-onoff:
- shard-tglb: [PASS][31] -> [SKIP][32] ([i915#668]) +3 similar issues
[31]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7924/shard-tglb8/igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-spr-indfb-onoff.html
[32]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4138/shard-tglb1/igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-spr-indfb-onoff.html
* igt@kms_plane_alpha_blend@pipe-a-alpha-basic:
- shard-tglb: [PASS][33] -> [FAIL][34] ([i915#1184])
[33]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7924/shard-tglb1/igt@kms_plane_alpha_blend@pipe-a-alpha-basic.html
[34]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4138/shard-tglb2/igt@kms_plane_alpha_blend@pipe-a-alpha-basic.html
* igt@kms_psr@psr2_primary_page_flip:
- shard-iclb: [PASS][35] -> [SKIP][36] ([fdo#109441]) +3 similar issues
[35]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7924/shard-iclb2/igt@kms_psr@psr2_primary_page_flip.html
[36]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4138/shard-iclb5/igt@kms_psr@psr2_primary_page_flip.html
* igt@kms_universal_plane@universal-plane-pipe-c-functional:
- shard-glk: [PASS][37] -> [FAIL][38] ([i915#331])
[37]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7924/shard-glk7/igt@kms_universal_plane@universal-plane-pipe-c-functional.html
[38]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4138/shard-glk3/igt@kms_universal_plane@universal-plane-pipe-c-functional.html
- shard-kbl: [PASS][39] -> [FAIL][40] ([i915#331])
[39]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7924/shard-kbl4/igt@kms_universal_plane@universal-plane-pipe-c-functional.html
[40]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4138/shard-kbl2/igt@kms_universal_plane@universal-plane-pipe-c-functional.html
- shard-apl: [PASS][41] -> [FAIL][42] ([i915#331])
[41]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7924/shard-apl3/igt@kms_universal_plane@universal-plane-pipe-c-functional.html
[42]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4138/shard-apl3/igt@kms_universal_plane@universal-plane-pipe-c-functional.html
* igt@kms_vblank@pipe-b-ts-continuation-dpms-suspend:
- shard-kbl: [PASS][43] -> [INCOMPLETE][44] ([fdo#103665])
[43]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7924/shard-kbl1/igt@kms_vblank@pipe-b-ts-continuation-dpms-suspend.html
[44]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4138/shard-kbl4/igt@kms_vblank@pipe-b-ts-continuation-dpms-suspend.html
* igt@perf@gen12-mi-rpc:
- shard-tglb: [PASS][45] -> [TIMEOUT][46] ([fdo#112271] / [i915#1085])
[45]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7924/shard-tglb7/igt@perf@gen12-mi-rpc.html
[46]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4138/shard-tglb1/igt@perf@gen12-mi-rpc.html
* igt@prime_vgem@fence-wait-bsd2:
- shard-iclb: [PASS][47] -> [SKIP][48] ([fdo#109276]) +13 similar issues
[47]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7924/shard-iclb2/igt@prime_vgem@fence-wait-bsd2.html
[48]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4138/shard-iclb7/igt@prime_vgem@fence-wait-bsd2.html
#### Possible fixes ####
* {igt@gem_ctx_persistence@legacy-engines-mixed-process@blt}:
- shard-apl: [FAIL][49] ([i915#679]) -> [PASS][50]
[49]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7924/shard-apl4/igt@gem_ctx_persistence@legacy-engines-mixed-process@blt.html
[50]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4138/shard-apl2/igt@gem_ctx_persistence@legacy-engines-mixed-process@blt.html
* {igt@gem_ctx_persistence@legacy-engines-mixed-process@vebox}:
- shard-apl: [INCOMPLETE][51] ([fdo#103927]) -> [PASS][52]
[51]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7924/shard-apl4/igt@gem_ctx_persistence@legacy-engines-mixed-process@vebox.html
[52]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4138/shard-apl2/igt@gem_ctx_persistence@legacy-engines-mixed-process@vebox.html
* igt@gem_eio@in-flight-suspend:
- shard-kbl: [DMESG-WARN][53] ([i915#180]) -> [PASS][54] +3 similar issues
[53]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7924/shard-kbl4/igt@gem_eio@in-flight-suspend.html
[54]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4138/shard-kbl4/igt@gem_eio@in-flight-suspend.html
* igt@gem_exec_schedule@pi-shared-iova-blt:
- shard-kbl: [INCOMPLETE][55] ([fdo#103665]) -> [PASS][56]
[55]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7924/shard-kbl3/igt@gem_exec_schedule@pi-shared-iova-blt.html
[56]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4138/shard-kbl1/igt@gem_exec_schedule@pi-shared-iova-blt.html
* igt@gem_exec_schedule@preempt-contexts-bsd2:
- shard-iclb: [SKIP][57] ([fdo#109276]) -> [PASS][58] +13 similar issues
[57]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7924/shard-iclb6/igt@gem_exec_schedule@preempt-contexts-bsd2.html
[58]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4138/shard-iclb1/igt@gem_exec_schedule@preempt-contexts-bsd2.html
* igt@gem_exec_schedule@preempt-other-chain-bsd:
- shard-iclb: [SKIP][59] ([fdo#112146]) -> [PASS][60] +4 similar issues
[59]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7924/shard-iclb1/igt@gem_exec_schedule@preempt-other-chain-bsd.html
[60]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4138/shard-iclb3/igt@gem_exec_schedule@preempt-other-chain-bsd.html
* igt@gem_mmap_gtt@basic-small-copy-xy:
- shard-snb: [DMESG-WARN][61] ([i915#478]) -> [PASS][62]
[61]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7924/shard-snb4/igt@gem_mmap_gtt@basic-small-copy-xy.html
[62]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4138/shard-snb6/igt@gem_mmap_gtt@basic-small-copy-xy.html
* igt@gem_partial_pwrite_pread@reads-uncached:
- shard-hsw: [FAIL][63] ([i915#694]) -> [PASS][64]
[63]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7924/shard-hsw6/igt@gem_partial_pwrite_pread@reads-uncached.html
[64]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4138/shard-hsw6/igt@gem_partial_pwrite_pread@reads-uncached.html
* igt@gem_tiled_partial_pwrite_pread@writes-after-reads:
- shard-hsw: [FAIL][65] -> [PASS][66]
[65]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7924/shard-hsw5/igt@gem_tiled_partial_pwrite_pread@writes-after-reads.html
[66]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4138/shard-hsw2/igt@gem_tiled_partial_pwrite_pread@writes-after-reads.html
* igt@gem_userptr_blits@sync-unmap:
- shard-snb: [DMESG-WARN][67] ([fdo#111870] / [i915#478]) -> [PASS][68]
[67]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7924/shard-snb6/igt@gem_userptr_blits@sync-unmap.html
[68]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4138/shard-snb5/igt@gem_userptr_blits@sync-unmap.html
* igt@i915_hangman@error-state-capture-vcs1:
- shard-iclb: [SKIP][69] ([fdo#112080]) -> [PASS][70] +7 similar issues
[69]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7924/shard-iclb8/igt@i915_hangman@error-state-capture-vcs1.html
[70]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4138/shard-iclb2/igt@i915_hangman@error-state-capture-vcs1.html
* igt@kms_big_fb@y-tiled-16bpp-rotate-270:
- shard-tglb: [FAIL][71] ([i915#1172]) -> [PASS][72]
[71]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7924/shard-tglb3/igt@kms_big_fb@y-tiled-16bpp-rotate-270.html
[72]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4138/shard-tglb6/igt@kms_big_fb@y-tiled-16bpp-rotate-270.html
* igt@kms_flip@flip-vs-suspend-interruptible:
- shard-apl: [DMESG-WARN][73] ([i915#180]) -> [PASS][74] +2 similar issues
[73]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7924/shard-apl8/igt@kms_flip@flip-vs-suspend-interruptible.html
[74]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4138/shard-apl7/igt@kms_flip@flip-vs-suspend-interruptible.html
* igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-indfb-draw-pwrite:
- shard-glk: [FAIL][75] ([i915#49]) -> [PASS][76]
[75]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7924/shard-glk6/igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-indfb-draw-pwrite.html
[76]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4138/shard-glk2/igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-indfb-draw-pwrite.html
* igt@kms_plane_alpha_blend@pipe-a-alpha-opaque-fb:
- shard-tglb: [FAIL][77] ([i915#1184]) -> [PASS][78]
[77]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7924/shard-tglb8/igt@kms_plane_alpha_blend@pipe-a-alpha-opaque-fb.html
[78]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4138/shard-tglb5/igt@kms_plane_alpha_blend@pipe-a-alpha-opaque-fb.html
* igt@kms_psr@psr2_suspend:
- shard-iclb: [SKIP][79] ([fdo#109441]) -> [PASS][80] +1 similar issue
[79]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7924/shard-iclb5/igt@kms_psr@psr2_suspend.html
[80]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4138/shard-iclb2/igt@kms_psr@psr2_suspend.html
* igt@kms_rotation_crc@multiplane-rotation-cropping-top:
- shard-tglb: [FAIL][81] ([i915#199]) -> [PASS][82]
[81]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7924/shard-tglb2/igt@kms_rotation_crc@multiplane-rotation-cropping-top.html
[82]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4138/shard-tglb5/igt@kms_rotation_crc@multiplane-rotation-cropping-top.html
* igt@kms_setmode@basic:
- shard-apl: [FAIL][83] ([i915#31]) -> [PASS][84]
[83]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7924/shard-apl6/igt@kms_setmode@basic.html
[84]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4138/shard-apl6/igt@kms_setmode@basic.html
* igt@prime_mmap_coherency@ioctl-errors:
- shard-hsw: [FAIL][85] ([i915#831]) -> [PASS][86]
[85]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7924/shard-hsw5/igt@prime_mmap_coherency@ioctl-errors.html
[86]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4138/shard-hsw6/igt@prime_mmap_coherency@ioctl-errors.html
#### Warnings ####
* igt@gem_tiled_blits@interruptible:
- shard-hsw: [FAIL][87] ([i915#818]) -> [FAIL][88] ([i915#694])
[87]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7924/shard-hsw1/igt@gem_tiled_blits@interruptible.html
[88]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4138/shard-hsw7/igt@gem_tiled_blits@interruptible.html
* igt@kms_dp_dsc@basic-dsc-enable-edp:
- shard-iclb: [DMESG-WARN][89] ([i915#1226]) -> [SKIP][90] ([fdo#109349])
[89]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7924/shard-iclb2/igt@kms_dp_dsc@basic-dsc-enable-edp.html
[90]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4138/shard-iclb8/igt@kms_dp_dsc@basic-dsc-enable-edp.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[CI#80]: https://gitlab.freedesktop.org/gfx-ci/i915-infra/issues/80
[fdo#103665]: https://bugs.freedesktop.org/show_bug.cgi?id=103665
[fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
[fdo#109276]: https://bugs.freedesktop.org/show_bug.cgi?id=109276
[fdo#109349]: https://bugs.freedesktop.org/show_bug.cgi?id=109349
[fdo#109441]: https://bugs.freedesktop.org/show_bug.cgi?id=109441
[fdo#111703]: https://bugs.freedesktop.org/show_bug.cgi?id=111703
[fdo#111870]: https://bugs.freedesktop.org/show_bug.cgi?id=111870
[fdo#112080]: https://bugs.freedesktop.org/show_bug.cgi?id=112080
[fdo#112146]: https://bugs.freedesktop.org/show_bug.cgi?id=112146
[fdo#112271]: https://bugs.freedesktop.org/show_bug.cgi?id=112271
[i915#1085]: https://gitlab.freedesktop.org/drm/intel/issues/1085
[i915#1172]: https://gitlab.freedesktop.org/drm/intel/issues/1172
[i915#1184]: https://gitlab.freedesktop.org/drm/intel/issues/1184
[i915#1226]: https://gitlab.freedesktop.org/drm/intel/issues/1226
[i915#180]: https://gitlab.freedesktop.org/drm/intel/issues/180
[i915#199]: https://gitlab.freedesktop.org/drm/intel/issues/199
[i915#31]: https://gitlab.freedesktop.org/drm/intel/issues/31
[i915#331]: https://gitlab.freedesktop.org/drm/intel/issues/331
[i915#42]: https://gitlab.freedesktop.org/drm/intel/issues/42
[i915#447]: https://gitlab.freedesktop.org/drm/intel/issues/447
[i915#478]: https://gitlab.freedesktop.org/drm/intel/issues/478
[i915#49]: https://gitlab.freedesktop.org/drm/intel/issues/49
[i915#54]: https://gitlab.freedesktop.org/drm/intel/issues/54
[i915#559]: https://gitlab.freedesktop.org/drm/intel/issues/559
[i915#61]: https://gitlab.freedesktop.org/drm/intel/issues/61
[i915#644]: https://gitlab.freedesktop.org/drm/intel/issues/644
[i915#668]: https://gitlab.freedesktop.org/drm/intel/issues/668
[i915#677]: https://gitlab.freedesktop.org/drm/intel/issues/677
[i915#679]: https://gitlab.freedesktop.org/drm/intel/issues/679
[i915#694]: https://gitlab.freedesktop.org/drm/intel/issues/694
[i915#818]: https://gitlab.freedesktop.org/drm/intel/issues/818
[i915#831]: https://gitlab.freedesktop.org/drm/intel/issues/831
Participating hosts (10 -> 8)
------------------------------
Missing (2): pig-skl-6260u pig-glk-j5005
Build changes
-------------
* CI: CI-20190529 -> None
* IGT: IGT_5436 -> IGTPW_4138
* Piglit: piglit_4509 -> None
CI-20190529: 20190529
CI_DRM_7924: d4ea682de87f4e4378f34f0a196e8fa8983bd306 @ git://anongit.freedesktop.org/gfx-ci/linux
IGTPW_4138: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4138/index.html
IGT_5436: 00a64098aaae2ac3154841d76c7b034165380282 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4138/index.html
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev
^ permalink raw reply
* Re: [PATCH v5 01/13] mm: Fix the return type of __do_page_cache_readahead
From: Matthew Wilcox @ 2020-02-14 19:50 UTC (permalink / raw)
To: linux-fsdevel
Cc: linux-xfs, linux-kernel, linux-f2fs-devel, cluster-devel,
linux-mm, ocfs2-devel, linux-ext4, linux-erofs, linux-btrfs
In-Reply-To: <20200211010348.6872-2-willy@infradead.org>
On Mon, Feb 10, 2020 at 05:03:36PM -0800, Matthew Wilcox wrote:
> From: "Matthew Wilcox (Oracle)" <willy@infradead.org>
>
> ra_submit() which is a wrapper around __do_page_cache_readahead() already
> returns an unsigned long, and the 'nr_to_read' parameter is an unsigned
> long, so fix __do_page_cache_readahead() to return an unsigned long,
> even though I'm pretty sure we're not going to readahead more than 2^32
> pages ever.
I was going through this and realised it's completely pointless -- the
returned value from ra_submit() and __do_page_cache_readahead() is
eventually ignored through all paths. So I'm replacing this patch with
one that makes everything return void.
^ permalink raw reply
* Re: RESEND: Re: Problem booting a PowerBook G4 Aluminum after commit cd08f109 with CONFIG_VMAP_STACK=y
From: Christophe Leroy @ 2020-02-14 19:35 UTC (permalink / raw)
To: Larry Finger; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <f3f628ca-4085-e9c2-2c62-170cf9801ac2@lwfinger.net>
On 02/14/2020 06:24 PM, Larry Finger wrote:
> On 2/14/20 12:24 AM, Christophe Leroy wrote:
>>
>> Did you try with the patch at
>> https://patchwork.ozlabs.org/patch/1237387/ ?
>
> Christophe,
>
> When I apply that patch, there is an error at
>
> --- a/arch/powerpc/kernel/head_32.S
> +++ b/arch/powerpc/kernel/head_32.S
> @@ -301,6 +301,39 @@ MachineCheck:
> . = 0x300
> DO_KVM 0x300
> DataAccess:
>
> It complains about "an attempt to move .org backwards".
>
Argh !
> When I change the 0x300 to 0x310 in two places, it builds OK. Is that OK?
No you can't do that.
The following should solve it for your case.
---
diff --git a/arch/powerpc/kernel/head_32.S b/arch/powerpc/kernel/head_32.S
index 32875afb3319..f9941b766f63 100644
--- a/arch/powerpc/kernel/head_32.S
+++ b/arch/powerpc/kernel/head_32.S
@@ -270,6 +270,9 @@ __secondary_hold_acknowledge:
* pointer when we take an exception from supervisor mode.)
* -- paulus.
*/
+#ifdef CONFIG_PPC_CHRP
+1: b machine_check_in_rtas
+#endif
. = 0x200
DO_KVM 0x200
MachineCheck:
@@ -290,12 +293,9 @@ MachineCheck:
7: EXCEPTION_PROLOG_2
addi r3,r1,STACK_FRAME_OVERHEAD
#ifdef CONFIG_PPC_CHRP
- bne cr1,1f
+ bne cr1,1b
#endif
EXC_XFER_STD(0x200, machine_check_exception)
-#ifdef CONFIG_PPC_CHRP
-1: b machine_check_in_rtas
-#endif
/* Data access exception. */
. = 0x300
---
Christophe
^ permalink raw reply related
* Re: [PATCH RFC] virtio_balloon: conservative balloon page shrinking
From: Tyler Sanderson via Virtualization @ 2020-02-14 20:22 UTC (permalink / raw)
To: Tetsuo Handa
Cc: mst@redhat.com, linux-kernel@vger.kernel.org,
virtualization@lists.linux-foundation.org, namit@vmware.com,
rientjes@google.com, alexander.h.duyck@linux.intel.com,
mhocko@kernel.org
In-Reply-To: <51306985-90ac-6e6b-d085-4e076698c48c@i-love.sakura.ne.jp>
[-- Attachment #1.1: Type: text/plain, Size: 3390 bytes --]
Sorry for the slow reply.
Re: Module parameters: I prefer not to have module parameters since they
are controlled by the guest. In general, in virtualized environments the
admins controlling the hypervisor are more knowledgeable about these things
than the users. A feature bit seems useful so that the host knows what the
guest behavior will be, and can change the host side implementation to make
the experience good for the guest.
I worry that requiring global_node_page_state(NR_FILE_PAGES) == 0 before
allowing deflation is too strict. One of the benefits of the shrinker API
is that it is invoked before vmscan.c has gone through heroic efforts to
reclaim the world. I'm not familiar enough with the code to judge how this
patch impacts this, but would it be beneficial to allow deflation when
vmscan.c is trying "too hard" to reclaim pages? Is there some softer
condition than "global_node_page_state(NR_FILE_PAGES) == 0"?
For my own understanding, does this patch work by returning 0 pages when
asked for pages? Are there cases where that results in an unnecessary OOM?
For example, if global_node_page_state(NR_FILE_PAGES) == 1, and the guest
needs 2?
Regarding other shrinkers (like KVM MMU cache): Reclaiming other shrinkers
first would match the behavior of DEFLATE_ON_OOM when it was using the OOM
notifier callback. On the other hand (awkwardly), the memory stats reported
on the stats queue for "available memory" do not count shrinker memory as
"available". So a balloon implementation that aims to reclaim some amount
of available memory would not be able to tell how much memory was in the
shrinkers and probably doesn't expect to reclaim them. For this reason, I
think only looking at page cache size is the right choice. There should be
a 1:1 relationship between stats reported and when DEFLATE_ON_OOM is
invoked. Maybe in the future we add another stat that reports shrinker
sizes, in which case we should also add a feature bit that allows other
shrinkers to be pressured.
Regarding NUMA awareness: I agree it's out of scope for this patch since
all implementations so far are not NUMA aware.
Would it be possible to back port this patch to 4.19 when the change to
shrinker API was made?
On Tue, Feb 11, 2020 at 6:20 AM Tetsuo Handa <
penguin-kernel@i-love.sakura.ne.jp> wrote:
> On 2020/02/10 16:27, Wang, Wei W wrote:
> >> Well, my comment is rather: "Do not try to reserve guest's memory. In
> other
> >> words, do not try to maintain balloons on the guest side. Since host
> would
> >> be able to cache file data on the host's cache, guests would be able to
> >> quickly fetch file data from host's cache via normal I/O requests." ;-)
> >
> > Didn't this one. The discussion was about guest pagecache pages v.s.
> guest balloon pages.
> > Why is host's pagecache here?
>
> I'm expecting a mode: "Guests should try to minimize pagecache pages (and
> teach
> host to treat reclaimed pages as if POSIX_FADV_DONTNEED) instead of
> managing
> guest balloon pages". In other words, as if
>
> while :; sleep 5; echo 1 > /proc/sys/vm/drop_caches; done
>
> is running in the guest's kernel. And as if
>
> echo 2 > /proc/sys/vm/drop_caches
>
> is triggered in the guest's kernel when host requested guests to reclaim
> memory. No long-life balloons. Guest balloons do not need to care about
> NUMA. Just leave the management of pagecache pages to the host.
>
>
[-- Attachment #1.2: Type: text/html, Size: 4038 bytes --]
[-- Attachment #2: Type: text/plain, Size: 183 bytes --]
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* [PATCH] btrfs: set update the uuid generation as soon as possible
From: Josef Bacik @ 2020-02-14 20:22 UTC (permalink / raw)
To: linux-btrfs, kernel-team
In my EIO stress testing I noticed I was getting forced to rescan the
uuid tree pretty often, which was weird. This is because my error
injection stuff would sometimes inject an error after log replay but
before we loaded the UUID tree. If log replay committed the transaction
it wouldn't have updated the uuid tree generation, but the tree was
valid and didn't change, so there's no reason to not update the
generation here.
Fix this by setting the BTRFS_FS_UPDATE_UUID_TREE_GEN bit immediately
after reading all the fs roots if the uuid tree generation matches the
fs generation. Then any transaction commits that happen during mount
won't screw up our uuid tree state, forcing us to do needless uuid
rescans.
Fixes: 70f801754728 ("Btrfs: check UUID tree during mount if required")
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
---
fs/btrfs/disk-io.c | 15 +++++++++++++--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c
index e3a2db4d09a6..772cf0fa7c55 100644
--- a/fs/btrfs/disk-io.c
+++ b/fs/btrfs/disk-io.c
@@ -3114,6 +3114,19 @@ int __cold open_ctree(struct super_block *sb, struct btrfs_fs_devices *fs_device
if (ret)
goto fail_tree_roots;
+ /*
+ * If we have a uuid root and we're not being told to rescan we need to
+ * check the generation here so we can set the
+ * BTRFS_FS_UPDATE_UUID_TREE_GEN bit. Otherwise we could commit the
+ * transaction during a balance or the log replay without updating the
+ * uuid generation, and then if we crash we would rescan the uuid tree,
+ * even though it was perfectly fine.
+ */
+ if (fs_info->uuid_root && !btrfs_test_opt(fs_info, RESCAN_UUID_TREE) &&
+ fs_info->generation ==
+ btrfs_super_uuid_tree_generation(disk_super))
+ set_bit(BTRFS_FS_UPDATE_UUID_TREE_GEN, &fs_info->flags);
+
ret = btrfs_verify_dev_extents(fs_info);
if (ret) {
btrfs_err(fs_info,
@@ -3338,8 +3351,6 @@ int __cold open_ctree(struct super_block *sb, struct btrfs_fs_devices *fs_device
close_ctree(fs_info);
return ret;
}
- } else {
- set_bit(BTRFS_FS_UPDATE_UUID_TREE_GEN, &fs_info->flags);
}
set_bit(BTRFS_FS_OPEN, &fs_info->flags);
--
2.24.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.