* [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
* RE: [PATCH] ACPICA: Fix a typo in acuuid.h
From: Moore, Robert @ 2020-02-14 20:21 UTC (permalink / raw)
To: Kaneda, Erik, Rafael J. Wysocki, Christophe JAILLET
Cc: lenb@kernel.org, linux-acpi@vger.kernel.org, devel@acpica.org,
linux-kernel@vger.kernel.org, kernel-janitors@vger.kernel.org
In-Reply-To: <BL0PR11MB29466C25466F5A88B4D4F5B9F0150@BL0PR11MB2946.namprd11.prod.outlook.com>
Ok, got it.
Thanks,
Bob
-
-----Original Message-----
From: Kaneda, Erik <erik.kaneda@intel.com>
Sent: Friday, February 14, 2020 9:08 AM
To: Rafael J. Wysocki <rjw@rjwysocki.net>; Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Cc: lenb@kernel.org; Moore, Robert <robert.moore@intel.com>; linux-acpi@vger.kernel.org; devel@acpica.org; linux-kernel@vger.kernel.org; kernel-janitors@vger.kernel.org
Subject: RE: [PATCH] ACPICA: Fix a typo in acuuid.h
> -----Original Message-----
> From: linux-acpi-owner@vger.kernel.org <linux-acpi-
> owner@vger.kernel.org> On Behalf Of Rafael J. Wysocki
> Sent: Friday, February 14, 2020 2:02 AM
> To: Christophe JAILLET <christophe.jaillet@wanadoo.fr>; Kaneda, Erik
> <erik.kaneda@intel.com>
> Cc: lenb@kernel.org; Moore, Robert <robert.moore@intel.com>; linux-
> acpi@vger.kernel.org; devel@acpica.org; linux-kernel@vger.kernel.org;
> kernel-janitors@vger.kernel.org
> Subject: Re: [PATCH] ACPICA: Fix a typo in acuuid.h
>
> On Friday, February 14, 2020 7:30:03 AM CET Christophe JAILLET wrote:
> > The comment related to the ending of the include guard should be
> > related to __ACUUID_H__, not __AUUID_H__ (i.e. 'C' is missing).
> >
> > Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
>
> Erik, please route this through the upstream.
Thanks for your patch!
I'll add it to our next release (in March)
Erik
>
> Thanks!
>
> > ---
> > include/acpi/acuuid.h | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/include/acpi/acuuid.h b/include/acpi/acuuid.h index
> > 9dd4689a39cf..9e1367b19069 100644
> > --- a/include/acpi/acuuid.h
> > +++ b/include/acpi/acuuid.h
> > @@ -57,4 +57,4 @@
> > #define UUID_THERMAL_EXTENSIONS "14d399cd-7a27-4b18-8fb4-
> 7cb7b9f4e500"
> > #define UUID_DEVICE_PROPERTIES "daffd814-6eba-4d8c-8a91-
> bc9bbf4aa301"
> >
> > -#endif/* __AUUID_H__ */
> > +#endif/* __ACUUID_H__ */
> >
>
>
>
^ permalink raw reply
* [Devel] Re: [PATCH] ACPICA: Fix a typo in acuuid.h
From: Moore, Robert @ 2020-02-14 20:21 UTC (permalink / raw)
To: devel
[-- Attachment #1: Type: text/plain, Size: 2039 bytes --]
Ok, got it.
Thanks,
Bob
-
-----Original Message-----
From: Kaneda, Erik <erik.kaneda(a)intel.com>
Sent: Friday, February 14, 2020 9:08 AM
To: Rafael J. Wysocki <rjw(a)rjwysocki.net>; Christophe JAILLET <christophe.jaillet(a)wanadoo.fr>
Cc: lenb(a)kernel.org; Moore, Robert <robert.moore(a)intel.com>; linux-acpi(a)vger.kernel.org; devel(a)acpica.org; linux-kernel(a)vger.kernel.org; kernel-janitors(a)vger.kernel.org
Subject: RE: [PATCH] ACPICA: Fix a typo in acuuid.h
> -----Original Message-----
> From: linux-acpi-owner(a)vger.kernel.org <linux-acpi-
> owner(a)vger.kernel.org> On Behalf Of Rafael J. Wysocki
> Sent: Friday, February 14, 2020 2:02 AM
> To: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr>; Kaneda, Erik
> <erik.kaneda(a)intel.com>
> Cc: lenb(a)kernel.org; Moore, Robert <robert.moore(a)intel.com>; linux-
> acpi(a)vger.kernel.org; devel(a)acpica.org; linux-kernel(a)vger.kernel.org;
> kernel-janitors(a)vger.kernel.org
> Subject: Re: [PATCH] ACPICA: Fix a typo in acuuid.h
>
> On Friday, February 14, 2020 7:30:03 AM CET Christophe JAILLET wrote:
> > The comment related to the ending of the include guard should be
> > related to __ACUUID_H__, not __AUUID_H__ (i.e. 'C' is missing).
> >
> > Signed-off-by: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr>
>
> Erik, please route this through the upstream.
Thanks for your patch!
I'll add it to our next release (in March)
Erik
>
> Thanks!
>
> > ---
> > include/acpi/acuuid.h | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/include/acpi/acuuid.h b/include/acpi/acuuid.h index
> > 9dd4689a39cf..9e1367b19069 100644
> > --- a/include/acpi/acuuid.h
> > +++ b/include/acpi/acuuid.h
> > @@ -57,4 +57,4 @@
> > #define UUID_THERMAL_EXTENSIONS "14d399cd-7a27-4b18-8fb4-
> 7cb7b9f4e500"
> > #define UUID_DEVICE_PROPERTIES "daffd814-6eba-4d8c-8a91-
> bc9bbf4aa301"
> >
> > -#endif/* __AUUID_H__ */
> > +#endif/* __ACUUID_H__ */
> >
>
>
>
^ permalink raw reply
* New Redfish roles for ServiceRep and OemRep
From: Joseph Reynolds @ 2020-02-14 20:21 UTC (permalink / raw)
To: openbmc
This is to propose two new Redfish roles:
The BMC Administrator should not have access to operations involving the
manufacturing process or servicing the host because these operations can
damage the system or cause unintended operation.
Examples of access needed:
1. ServiceRep - Needs to access BMC operations to service the system,
such as re-enabling locked out field replaceable units (FRUs) after
replacing a defective unit.
2. OemRep - Needs to access BMC operations to test the host system, such
as how the system responds to overheating.
I believe these roles are clearly distinct from role=Administrator or
any other role.
The roles should NOT have access to the BMC's configuration or user
management. For example, the BMC admin will be able to lock out any
service agent or OemRep using the regular user management functions.
Does anyone else need for these roles? If so, I will try to get them
into Redfish.
- Joseph
This topic was discussed briefly in the OpenBMC security working group,
2019-11-27:
https://docs.google.com/document/d/1b7x9BaxsfcukQDqbvZsU2ehMq4xoJRQvLxxsDUWmAOI
See also: https://github.com/ibm-openbmc/dev/issues/1529
^ permalink raw reply
* Re: [Virtio-fs] fedora packages for virtiofsd
From: Daniel Walsh @ 2020-02-14 20:20 UTC (permalink / raw)
To: Dr. David Alan Gilbert, Vivek Goyal, crobinso
Cc: virtio-fs-list, Mrunal Patel
In-Reply-To: <20200214194437.GQ3283@work-vm>
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.
^ permalink raw reply
* Re: [PATCH userspace v2] libsepol: cache ebitmap cardinality value
From: Ondrej Mosnacek @ 2020-02-14 20:19 UTC (permalink / raw)
To: Stephen Smalley; +Cc: SElinux list, James Carter
In-Reply-To: <CAFqZXNtpqOszQ5a2s86TTHtQGK_c+vqmtaRPBv04+vFAqExEmg@mail.gmail.com>
On Fri, Feb 14, 2020 at 8:51 PM Ondrej Mosnacek <omosnace@redhat.com> wrote:
> On Fri, Feb 14, 2020 at 6:37 PM Stephen Smalley <sds@tycho.nsa.gov> wrote:
> > On 2/13/20 8:39 AM, Ondrej Mosnacek wrote:
> > > According to profiling of semodule -BN, ebitmap_cardinality() is called
> > > quite often and contributes a lot to the total runtime. Cache its result
> > > in the ebitmap struct to reduce this overhead. The cached value is
> > > invalidated on most modifying operations, but ebitmap_cardinality() is
> > > usually called once the ebitmap doesn't change any more.
> > >
> > > After this patch, the time to do 'semodule -BN' on Fedora Rawhide has
> > > decreased from ~14.6s to ~12.4s (2.2s saved).
> > >
> > > Signed-off-by: Ondrej Mosnacek <omosnace@redhat.com>
> >
> > This seems fine but I was wondering how many of the callers of
> > ebitmap_cardinality() actually need anything more than ebitmap_length()?
>
> The caller that calls it the most (>99%) during a 'semodule -B' is
> __cil_should_expand_attribute(), which logically needs the actual
> cardinality. It might be possible to cache the decision directly in
> 'struct cil_typeattribute', but I don't know the CIL code well enough
> to attempt that...
BTW, in case anyone is wondering how I'm getting these numbers/facts -
I use Callgrind [1] to profile a program's run and then analyze it
with KCachegrind [2]. It is a surprisingly nice and easy to use GUI
for analyzing where the program spends most of its time.
Collecting the profile data is as simple as:
LD_BIND_NOW=1 valgrind --tool=callgrind <your_command> <args>...
(The LD_BIND_NOW=1 is to prevent the dynamic linker's lazy binding
from messing with the results.)
Then you can just open the generated "callgrind.out.<pid>" file with
KCachegrind and click around... Note that to see the function names,
you need to compile the program with -g (but you should keep -O2 et
al. to get the same optimized code as an actual build). Alternatively,
Callgrind will also auto-detect and use debug symbols provided by
distributions in their -debug/-debuginfo packages.
Maybe this is common knowledge for most, but perhaps someone here will
be one of today's lucky 10000 :) [3]
[1] https://valgrind.org/docs/manual/cl-manual.html
[2] https://kcachegrind.github.io/html/Home.html
[3] https://xkcd.com/1053/
--
Ondrej Mosnacek <omosnace at redhat dot com>
Software Engineer, Security Technologies
Red Hat, Inc.
^ permalink raw reply
* Re: RESEND: Re: Problem booting a PowerBook G4 Aluminum after commit cd08f109 with CONFIG_VMAP_STACK=y
From: Larry Finger @ 2020-02-14 18:24 UTC (permalink / raw)
To: Christophe Leroy; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <02ce1278-5880-063c-2281-178edd541232@c-s.fr>
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".
When I change the 0x300 to 0x310 in two places, it builds OK. Is that OK?
Larry
^ 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: linux-nvdimm, Aneesh Kumar K.V, vishal.l.verma, linux-kernel,
linuxppc-dev
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 4/4] libnvdimm/region: Introduce an 'align' attribute
From: Jeff Moyer @ 2020-02-14 20:19 UTC (permalink / raw)
To: Dan Williams; +Cc: linux-nvdimm, Aneesh Kumar K.V, linux-kernel, linuxppc-dev
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>
_______________________________________________
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-leave@lists.01.org
^ permalink raw reply
* [PATCH v3] x86/cpu/amd: Enable the fixed Instructions Retired counter IRPERF
From: Kim Phillips @ 2020-02-14 20:18 UTC (permalink / raw)
To: Peter Zijlstra, Ingo Molnar, Ingo Molnar, Borislav Petkov,
kim.phillips
Cc: Alexander Shishkin, Andi Kleen, Arnaldo Carvalho de Melo,
Babu Moger, Fenghua Yu, Frank van der Linden, H . Peter Anvin,
Huang Rui, Janakarajan Natarajan, Jan Beulich, Jiaxun Yang,
Jiri Olsa, Josh Poimboeuf, Linus Torvalds, Luwei Kang,
Martin Liška, Matt Fleming, Michael Petlan, Namhyung Kim,
Paolo Bonzini, Pawan Gupta, Suravee Suthikulpanit,
Thomas Gleixner, Tom Lendacky, x86, linux-kernel, stable
Commit aaf248848db50 ("perf/x86/msr: Add AMD IRPERF (Instructions
Retired) performance counter") added support for access to the
free-running counter via 'perf -e msr/irperf/', but when exercised,
we always get a 0 count:
BEFORE:
$ sudo perf stat -e instructions,msr/irperf/ true
Performance counter stats for 'true':
624,833 instructions
0 msr/irperf/
Simply set its enable bit - HWCR bit 30 - to make it start counting.
Enablement is restricted to all machines advertising IRPERF capability,
except those susceptible to an erratum that makes the IRPERF return
bad values.
That erratum occurs in Family 17h models 00-1fh [1], but not in F17h
models 20h and above [2].
AFTER (on a family 17h model 31h machine):
$ sudo perf stat -e instructions,msr/irperf/ true
Performance counter stats for 'true':
621,690 instructions
622,490 msr/irperf/
[1] Revision Guide for AMD Family 17h Models 00h-0Fh Processors
[2] Revision Guide for AMD Family 17h Models 30h-3Fh Processors
The revision guides are available from the bugzilla Link below.
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
Cc: Babu Moger <babu.moger@amd.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Fenghua Yu <fenghua.yu@intel.com>
Cc: Frank van der Linden <fllinden@amazon.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Huang Rui <ray.huang@amd.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Janakarajan Natarajan <Janakarajan.Natarajan@amd.com>
Cc: Jan Beulich <jbeulich@suse.com>
Cc: Jiaxun Yang <jiaxun.yang@flygoat.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Luwei Kang <luwei.kang@intel.com>
Cc: Martin Liška <mliska@suse.cz>
Cc: Matt Fleming <matt@codeblueprint.co.uk>
Cc: Michael Petlan <mpetlan@redhat.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: x86@kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: stable@vger.kernel.org
Link: https://bugzilla.kernel.org/show_bug.cgi?id=206537
Fixes: aaf248848db50 ("perf/x86/msr: Add AMD IRPERF (Instructions Retired) performance counter")
Signed-off-by: Kim Phillips <kim.phillips@amd.com>
---
v3: Removed null stalled cycles per insn from perf example output,
since it got fixed, also address comments from Borislav Petkov:
https://lkml.org/lkml/2020/2/11/395
- rephrase commit text to not say "this patch".
- uploaded both rev. guides (and all public F17h PPRs)
to a new "Add AMD x86 documents for future reference"
bug, and reference that in a Link: tag.
- rename X86_BUG_AMD_E1054 -> X86_BUG_IRPERF
- add a full stop to a sentence in a comment
v2 got resent, adding Michael Petlan to cc. Original v2:
https://lore.kernel.org/lkml/20200121171232.28839-2-kim.phillips@amd.com/
v2: Based on Andi Kleen's review:
https://lore.kernel.org/lkml/20200116040324.GI302770@tassilo.jf.intel.com/
Add an amd_erratum_1054 and use cpu_has_bug infrastructure
instead of open-coding the {family,model} check.
arch/x86/include/asm/cpufeatures.h | 1 +
arch/x86/include/asm/msr-index.h | 2 ++
arch/x86/kernel/cpu/amd.c | 17 +++++++++++++++++
3 files changed, 20 insertions(+)
diff --git a/arch/x86/include/asm/cpufeatures.h b/arch/x86/include/asm/cpufeatures.h
index f3327cb56edf..8979d6fcc79c 100644
--- a/arch/x86/include/asm/cpufeatures.h
+++ b/arch/x86/include/asm/cpufeatures.h
@@ -404,5 +404,6 @@
#define X86_BUG_SWAPGS X86_BUG(21) /* CPU is affected by speculation through SWAPGS */
#define X86_BUG_TAA X86_BUG(22) /* CPU is affected by TSX Async Abort(TAA) */
#define X86_BUG_ITLB_MULTIHIT X86_BUG(23) /* CPU may incur MCE during certain page attribute changes */
+#define X86_BUG_IRPERF X86_BUG(24) /* CPU is affected by Instructions Retired counter Erratum 1054 */
#endif /* _ASM_X86_CPUFEATURES_H */
diff --git a/arch/x86/include/asm/msr-index.h b/arch/x86/include/asm/msr-index.h
index ebe1685e92dd..d5e517d1c3dd 100644
--- a/arch/x86/include/asm/msr-index.h
+++ b/arch/x86/include/asm/msr-index.h
@@ -512,6 +512,8 @@
#define MSR_K7_HWCR 0xc0010015
#define MSR_K7_HWCR_SMMLOCK_BIT 0
#define MSR_K7_HWCR_SMMLOCK BIT_ULL(MSR_K7_HWCR_SMMLOCK_BIT)
+#define MSR_K7_HWCR_IRPERF_EN_BIT 30
+#define MSR_K7_HWCR_IRPERF_EN BIT_ULL(MSR_K7_HWCR_IRPERF_EN_BIT)
#define MSR_K7_FID_VID_CTL 0xc0010041
#define MSR_K7_FID_VID_STATUS 0xc0010042
diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
index ac83a0fef628..deebc728e2aa 100644
--- a/arch/x86/kernel/cpu/amd.c
+++ b/arch/x86/kernel/cpu/amd.c
@@ -28,6 +28,7 @@
static const int amd_erratum_383[];
static const int amd_erratum_400[];
+static const int amd_erratum_1054[];
static bool cpu_has_amd_erratum(struct cpuinfo_x86 *cpu, const int *erratum);
/*
@@ -694,6 +695,9 @@ static void early_init_amd(struct cpuinfo_x86 *c)
if (cpu_has_amd_erratum(c, amd_erratum_400))
set_cpu_bug(c, X86_BUG_AMD_E400);
+ if (cpu_has_amd_erratum(c, amd_erratum_1054))
+ set_cpu_bug(c, X86_BUG_IRPERF);
+
early_detect_mem_encrypt(c);
/* Re-enable TopologyExtensions if switched off by BIOS */
@@ -972,6 +976,15 @@ static void init_amd(struct cpuinfo_x86 *c)
/* AMD CPUs don't reset SS attributes on SYSRET, Xen does. */
if (!cpu_has(c, X86_FEATURE_XENPV))
set_cpu_bug(c, X86_BUG_SYSRET_SS_ATTRS);
+
+ /*
+ * Turn on the Instructions Retired free counter on machines not
+ * susceptible to erratum #1054 "Instructions Retired Performance
+ * Counter May Be Inaccurate".
+ */
+ if (cpu_has(c, X86_FEATURE_IRPERF) &&
+ !cpu_has_bug(c, X86_BUG_IRPERF))
+ msr_set_bit(MSR_K7_HWCR, MSR_K7_HWCR_IRPERF_EN_BIT);
}
#ifdef CONFIG_X86_32
@@ -1099,6 +1112,10 @@ static const int amd_erratum_400[] =
static const int amd_erratum_383[] =
AMD_OSVW_ERRATUM(3, AMD_MODEL_RANGE(0x10, 0, 0, 0xff, 0xf));
+/* #1054: Instructions Retired Performance Counter May Be Inaccurate */
+static const int amd_erratum_1054[] =
+ AMD_OSVW_ERRATUM(0, AMD_MODEL_RANGE(0x17, 0, 0, 0x2f, 0xf));
+
static bool cpu_has_amd_erratum(struct cpuinfo_x86 *cpu, const int *erratum)
{
--
2.25.0
^ permalink raw reply related
* Re: [PATCH 02/10] riscv: Force flat memory model with no-mmu
From: Sean Anderson @ 2020-02-14 20:18 UTC (permalink / raw)
To: Damien Le Moal, linux-riscv, Palmer Dabbelt; +Cc: Anup Patel, Paul Walmsley
In-Reply-To: <20200212103432.660256-3-damien.lemoal@wdc.com>
Hi,
On 2/12/20 5:34 AM, Damien Le Moal wrote:
> Compilation errors trigger if ARCH_SPARSEMEM_ENABLE is enabled for
> a nommu kernel. Since the sparsemem model does not make sense anyway
> for the nommu case, do not allow selecting this option to always use
> the flatmem model.
>
> Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
> ---
> arch/riscv/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> index 73f029eae0cc..1a3b5a5276be 100644
> --- a/arch/riscv/Kconfig
> +++ b/arch/riscv/Kconfig
> @@ -121,6 +121,7 @@ config ARCH_FLATMEM_ENABLE
>
> config ARCH_SPARSEMEM_ENABLE
> def_bool y
> + depends on MMU
> select SPARSEMEM_VMEMMAP_ENABLE
>
> config ARCH_SELECT_MEMORY_MODEL
>
Just for some background, why did you choose NOMMU? Afaik the K210 has
an MMU following the RISC-V privileged specification 1.9
--Sean
^ permalink raw reply
* Re: [Letux-kernel] [PATCH v2] net: davicom: dm9000: allow to pass MAC address through mac_addr module parameter
From: Paul Cercueil @ 2020-02-14 20:17 UTC (permalink / raw)
To: H. Nikolaus Schaller
Cc: Andrew Lunn, netdev, Linux Kernel Mailing List, Richard Fontana,
Thomas Gleixner, kernel, Petr Štetiar, David S. Miller,
Heiner Kallweit, Discussions about the Letux Kernel
In-Reply-To: <85A043D6-118A-4940-9DB2-5C6517DBCC78@goldelico.com>
Le ven., févr. 14, 2020 at 21:05, H. Nikolaus Schaller
<hns@goldelico.com> a écrit :
>
>> Am 14.02.2020 um 20:38 schrieb H. Nikolaus Schaller
>> <hns@goldelico.com>:
>>
>>
>>> Am 14.02.2020 um 20:24 schrieb H. Nikolaus Schaller
>>> <hns@goldelico.com>:
>>>
>>>
>>>> Am 14.02.2020 um 19:47 schrieb Paul Cercueil
>>>> <paul@crapouillou.net>:
>>>>
>>>> Hi Nikolaus,
>>>>
>>>> What I'd suggest is to write a NVMEM driver for the efuse and
>>>> retrieve the MAC address cleanly with nvmem_get_mac_address().
>>>>
>>>> It shouldn't be hard to do (there's already code for it in the
>>>> non-upstream 3.18 kernel for the CI20) and you remove the
>>>> dependency on uboot.
>>>
>>> Interesting approach. I have found this:
>>>
>>> https://lore.kernel.org/patchwork/patch/868158/
>>>
>>> but it looks as if it was never finished (I could not locate a V3
>>> or anything mainline?)
>>> and and it tries to solve other problems as well.
>>>
>>> And it looks to be much more complex than my "solution" to the
>>> immediate problem.
>>>
>>> I have to study it to know if I can write a
>>> nvmem_get_mac_address().
>>
>> Another question is how to link this very jz4780 specific code to
>> the generic davicom dm9000 driver?
>> And where should the new code live. In some jz4780 specific file or
>> elsewhere?
>
> Ok, got it.
>
> nvmem_get_mac_address() is looking for a nvmem cell "mac-address".
>
> So some jz4780 specific driver must provide such cells.
No, the jz4780 specific driver should just provide the functionality.
The cells are provided in devicetree, just like in the two
documentation files I listed before.
-Paul
>
> There aren't many examples but it appears as if
> arch/arm/mach-davinci/board-da830-evm.c
> defines and registers nvmem cells.
>
> But maybe it is not difficult to teach the 2018 driver to provide
> such cells.
>
> BR and thanks,
> Nikolaus
>
>
>>
>>>
>>> BR,
>>> Nikolaus
>>>
>>>>
>>>> -Paul
>>>>
>>>>
>>>> Le ven., févr. 14, 2020 at 17:07, H. Nikolaus Schaller
>>>> <hns@goldelico.com> a écrit :
>>>>> The MIPS Ingenic CI20 board is shipped with a quite old u-boot
>>>>> (ci20-v2013.10 see https://elinux.org/CI20_Dev_Zone). This passes
>>>>> the MAC address through dm9000.mac_addr=xx:xx:xx:xx:xx:xx
>>>>> kernel module parameter to give the board a fixed MAC address.
>>>>> This is not processed by the dm9000 driver which assigns a random
>>>>> MAC address on each boot, making DHCP assign a new IP address
>>>>> each time.
>>>>> So we add a check for the mac_addr module parameter as a last
>>>>> resort before assigning a random one. This mechanism can also
>>>>> be used outside of u-boot to provide a value through modprobe
>>>>> config.
>>>>> To parse the MAC address in a new function get_mac_addr() we
>>>>> use an copy adapted from the ksz884x.c driver which provides
>>>>> the same functionality.
>>>>> Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
>>>>> ---
>>>>> drivers/net/ethernet/davicom/dm9000.c | 42
>>>>> +++++++++++++++++++++++++++
>>>>> 1 file changed, 42 insertions(+)
>>>>> diff --git a/drivers/net/ethernet/davicom/dm9000.c
>>>>> b/drivers/net/ethernet/davicom/dm9000.c
>>>>> index 1ea3372775e6..7402030b0352 100644
>>>>> --- a/drivers/net/ethernet/davicom/dm9000.c
>>>>> +++ b/drivers/net/ethernet/davicom/dm9000.c
>>>>> @@ -1409,6 +1409,43 @@ static struct dm9000_plat_data
>>>>> *dm9000_parse_dt(struct device *dev)
>>>>> return pdata;
>>>>> }
>>>>> +static char *mac_addr = ":";
>>>>> +module_param(mac_addr, charp, 0);
>>>>> +MODULE_PARM_DESC(mac_addr, "MAC address");
>>>>> +
>>>>> +static void get_mac_addr(struct net_device *ndev, char *macaddr)
>>>>> +{
>>>>> + int i = 0;
>>>>> + int j = 0;
>>>>> + int got_num = 0;
>>>>> + int num = 0;
>>>>> +
>>>>> + while (j < ETH_ALEN) {
>>>>> + if (macaddr[i]) {
>>>>> + int digit;
>>>>> +
>>>>> + got_num = 1;
>>>>> + digit = hex_to_bin(macaddr[i]);
>>>>> + if (digit >= 0)
>>>>> + num = num * 16 + digit;
>>>>> + else if (':' == macaddr[i])
>>>>> + got_num = 2;
>>>>> + else
>>>>> + break;
>>>>> + } else if (got_num) {
>>>>> + got_num = 2;
>>>>> + } else {
>>>>> + break;
>>>>> + }
>>>>> + if (got_num == 2) {
>>>>> + ndev->dev_addr[j++] = (u8)num;
>>>>> + num = 0;
>>>>> + got_num = 0;
>>>>> + }
>>>>> + i++;
>>>>> + }
>>>>> +}
>>>>> +
>>>>> /*
>>>>> * Search DM9000 board, allocate space and register it
>>>>> */
>>>>> @@ -1679,6 +1716,11 @@ dm9000_probe(struct platform_device *pdev)
>>>>> ndev->dev_addr[i] = ior(db, i+DM9000_PAR);
>>>>> }
>>>>> + if (!is_valid_ether_addr(ndev->dev_addr)) {
>>>>> + mac_src = "param";
>>>>> + get_mac_addr(ndev, mac_addr);
>>>>> + }
>>>>> +
>>>>> if (!is_valid_ether_addr(ndev->dev_addr)) {
>>>>> inv_mac_addr = true;
>>>>> eth_hw_addr_random(ndev);
>>>>> --
>>>>> 2.23.0
>>>>
>>>>
>>>
>>> _______________________________________________
>>> http://projects.goldelico.com/p/gta04-kernel/
>>> Letux-kernel mailing list
>>> Letux-kernel@openphoenux.org
>>> http://lists.goldelico.com/mailman/listinfo.cgi/letux-kernel
>>
>> _______________________________________________
>> http://projects.goldelico.com/p/gta04-kernel/
>> Letux-kernel mailing list
>> Letux-kernel@openphoenux.org
>> http://lists.goldelico.com/mailman/listinfo.cgi/letux-kernel
>
^ permalink raw reply
* Re: [PATCH v2 11/21] target/arm: Move DBGDIDR into ARMISARegisters
From: Richard Henderson @ 2020-02-14 20:16 UTC (permalink / raw)
To: Peter Maydell, qemu-arm, qemu-devel
Cc: Eric Auger, Aaron Lindsay, Philippe Mathieu-Daudé
In-Reply-To: <20200214175116.9164-12-peter.maydell@linaro.org>
On 2/14/20 9:51 AM, Peter Maydell wrote:
> We're going to want to read the DBGDIDR register from KVM in
> a subsequent commit, which means it needs to be in the
> ARMISARegisters sub-struct. Move it.
>
> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
> ---
> target/arm/cpu.h | 2 +-
> target/arm/internals.h | 6 +++---
> target/arm/cpu.c | 8 ++++----
> target/arm/cpu64.c | 6 +++---
> target/arm/helper.c | 2 +-
> 5 files changed, 12 insertions(+), 12 deletions(-)
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
r~
^ permalink raw reply
* Re: [PATCH v2 10/21] target/arm: Stop assuming DBGDIDR always exists
From: Richard Henderson @ 2020-02-14 20:15 UTC (permalink / raw)
To: Peter Maydell, qemu-arm, qemu-devel
Cc: Eric Auger, Aaron Lindsay, Philippe Mathieu-Daudé
In-Reply-To: <20200214175116.9164-11-peter.maydell@linaro.org>
On 2/14/20 9:51 AM, Peter Maydell wrote:
> The AArch32 DBGDIDR defines properties like the number of
> breakpoints, watchpoints and context-matching comparators. On an
> AArch64 CPU, the register may not even exist if AArch32 is not
> supported at EL1.
>
> Currently we hard-code use of DBGDIDR to identify the number of
> breakpoints etc; this works for all our TCG CPUs, but will break if
> we ever add an AArch64-only CPU. We also have an assert() that the
> AArch32 and AArch64 registers match, which currently works only by
> luck for KVM because we don't populate either of these ID registers
> from the KVM vCPU and so they are both zero.
>
> Clean this up so we have functions for finding the number
> of breakpoints, watchpoints and context comparators which look
> in the appropriate ID register.
>
> This allows us to drop the "check that AArch64 and AArch32 agree
> on the number of breakpoints etc" asserts:
> * we no longer look at the AArch32 versions unless that's the
> right place to be looking
> * it's valid to have a CPU (eg AArch64-only) where they don't match
> * we shouldn't have been asserting the validity of ID registers
> in a codepath used with KVM anyway
>
> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
> ---
> target/arm/cpu.h | 7 +++++++
> target/arm/internals.h | 42 +++++++++++++++++++++++++++++++++++++++
> target/arm/debug_helper.c | 6 +++---
> target/arm/helper.c | 21 +++++---------------
> 4 files changed, 57 insertions(+), 19 deletions(-)
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
r~
^ permalink raw reply
* Re: RESEND: Re: Problem booting a PowerBook G4 Aluminum after commit cd08f109 with CONFIG_VMAP_STACK=y
From: Larry Finger @ 2020-02-14 18:20 UTC (permalink / raw)
To: Christophe Leroy; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <02ce1278-5880-063c-2281-178edd541232@c-s.fr>
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".
Larry
^ permalink raw reply
* Re: About r8169 regression 5.4
From: Heiner Kallweit @ 2020-02-14 20:14 UTC (permalink / raw)
To: Vincas Dargis; +Cc: netdev
In-Reply-To: <b46d29d8-faf6-351e-0d9f-a4d4c043a54c@gmail.com>
On 14.02.2020 18:21, Vincas Dargis wrote:
> Hi,
>
> I've found similar issue I have myself since 5.4 on mailing list archive [0], for this device:
>
Thanks for reporting. As you refer to [0], do you use jumbo packets?
> 05:00.1 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 12)
> Subsystem: ASUSTeK Computer Inc. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
>
>
> It works fine as long as I select 5.3 in Grub (it seems no longer maintained in Debian Sid though...)
>
> I see number of commits in net/etherenet/realtek tree, not sure if fix is there, or do we need another fix for this particular device? I've keep testing latest Debian kernel updates (latest is 5.4.19-1), and no good news yet.
>
Best of course would be a bisect between 5.3 and 5.4. Can you do this?
I have no test hardware with this chip version (RTL8411B).
You could also try to revert a7a92cf81589 ("r8169: sync PCIe PHY init with vendor driver 8.047.01")
and check whether this fixes your issue.
In addition you could test latest 5.5-rc, or linux-next.
> There's Debian bug report [1] which might contain more information.
>
> Some extra info:
>
> $ sudo ethtool -i enp5s0f1
> driver: r8169
> version:
> firmware-version: rtl8411-2_0.0.1 07/08/13
> expansion-rom-version:
> bus-info: 0000:05:00.1
> supports-statistics: yes
> supports-test: no
> supports-eeprom-access: no
> supports-register-dump: yes
> supports-priv-flags: no
>
>
> $ sudo mii-tool -v enp5s0f1
> enp5s0f1: negotiated 1000baseT-FD flow-control, link ok
> product info: vendor 00:07:32, model 0 rev 0
> basic mode: autonegotiation enabled
> basic status: autonegotiation complete, link ok
> capabilities: 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
> advertising: 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control
> link partner: 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control
>
>
> [0] https://lkml.org/lkml/2019/11/30/119
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=947685
Heiner
^ permalink raw reply
* arm-smmu.1.auto: Unhandled context fault starting with 5.4-rc1
From: Jerry Snitselaar @ 2020-02-14 20:13 UTC (permalink / raw)
To: iommu, Will Deacon
Hi Will,
On a gigabyte system with Cavium CN8xx, when doing a fio test against
an nvme drive we are seeing the following:
[ 637.161194] arm-smmu arm-smmu.1.auto: Unhandled context fault: fsr=0x80000402, iova=0x8010003f6000, fsynr=0x70091, cbfrsynra=0x9000, cb=7
[ 637.174329] arm-smmu arm-smmu.1.auto: Unhandled context fault: fsr=0x80000402, iova=0x801000036000, fsynr=0x70091, cbfrsynra=0x9000, cb=7
[ 637.186887] arm-smmu arm-smmu.1.auto: Unhandled context fault: fsr=0x80000402, iova=0x8010002ee000, fsynr=0x70091, cbfrsynra=0x9000, cb=7
[ 637.199275] arm-smmu arm-smmu.1.auto: Unhandled context fault: fsr=0x80000402, iova=0x8010003c7000, fsynr=0x70091, cbfrsynra=0x9000, cb=7
[ 637.211885] arm-smmu arm-smmu.1.auto: Unhandled context fault: fsr=0x80000402, iova=0x801000392000, fsynr=0x70091, cbfrsynra=0x9000, cb=7
[ 637.224580] arm-smmu arm-smmu.1.auto: Unhandled context fault: fsr=0x80000402, iova=0x801000018000, fsynr=0x70091, cbfrsynra=0x9000, cb=7
[ 637.237241] arm-smmu arm-smmu.1.auto: Unhandled context fault: fsr=0x80000402, iova=0x801000360000, fsynr=0x70091, cbfrsynra=0x9000, cb=7
[ 637.249657] arm-smmu arm-smmu.1.auto: Unhandled context fault: fsr=0x80000402, iova=0x8010000ba000, fsynr=0x70091, cbfrsynra=0x9000, cb=7
[ 637.262120] arm-smmu arm-smmu.1.auto: Unhandled context fault: fsr=0x80000402, iova=0x80100003e000, fsynr=0x70091, cbfrsynra=0x9000, cb=7
[ 637.274468] arm-smmu arm-smmu.1.auto: Unhandled context fault: fsr=0x80000402, iova=0x801000304000, fsynr=0x70091, cbfrsynra=0x9000, cb=7
I also reproduced with 5.5-rc7, and will check 5.6-rc1 later today. I couldn't narrow it down further into 5.4-rc1.
I don't know smmu or the code well, any thoughts on where to start digging into this?
fio test that is being run is:
#fio -filename=/dev/nvme0n1 -iodepth=64 -thread -rw=randwrite -ioengine=libaio -bs=4k -runtime=43200 -size=-group_reporting -name=mytest -numjobs=32
Regards,
Jerry
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply
* [PATCH 6/7] commit: Expose on-error option in QMP
From: Kevin Wolf @ 2020-02-14 20:08 UTC (permalink / raw)
To: qemu-block; +Cc: kwolf, pkrempa, qemu-devel, mreitz, nsoffer, jsnow
In-Reply-To: <20200214200812.28180-1-kwolf@redhat.com>
Now that the error handling in the common block job is fixed, we can
expose the on-error option in QMP instead of hard-coding it as 'report'
in qmp_block_commit().
This fulfills the promise that the old comment in that function made,
even if a bit later than expected: "This will be part of the QMP
command, if/when the BlockdevOnError change for blkmirror makes it in".
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
---
qapi/block-core.json | 4 ++++
blockdev.c | 8 ++++----
2 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/qapi/block-core.json b/qapi/block-core.json
index 395d205fa8..c69aece46e 100644
--- a/qapi/block-core.json
+++ b/qapi/block-core.json
@@ -1659,6 +1659,9 @@
#
# @speed: the maximum speed, in bytes per second
#
+# @on-error: the action to take on an error. 'ignore' means that the request
+# should be retried. (default: report; Since: 5.0)
+#
# @filter-node-name: the node name that should be assigned to the
# filter driver that the commit job inserts into the graph
# above @top. If this option is not given, a node name is
@@ -1695,6 +1698,7 @@
'data': { '*job-id': 'str', 'device': 'str', '*base-node': 'str',
'*base': 'str', '*top-node': 'str', '*top': 'str',
'*backing-file': 'str', '*speed': 'int',
+ '*on-error': 'BlockdevOnError',
'*filter-node-name': 'str',
'*auto-finalize': 'bool', '*auto-dismiss': 'bool' } }
diff --git a/blockdev.c b/blockdev.c
index c6a727cca9..374189a426 100644
--- a/blockdev.c
+++ b/blockdev.c
@@ -3471,6 +3471,7 @@ void qmp_block_commit(bool has_job_id, const char *job_id, const char *device,
bool has_top, const char *top,
bool has_backing_file, const char *backing_file,
bool has_speed, int64_t speed,
+ bool has_on_error, BlockdevOnError on_error,
bool has_filter_node_name, const char *filter_node_name,
bool has_auto_finalize, bool auto_finalize,
bool has_auto_dismiss, bool auto_dismiss,
@@ -3481,15 +3482,14 @@ void qmp_block_commit(bool has_job_id, const char *job_id, const char *device,
BlockDriverState *base_bs, *top_bs;
AioContext *aio_context;
Error *local_err = NULL;
- /* This will be part of the QMP command, if/when the
- * BlockdevOnError change for blkmirror makes it in
- */
- BlockdevOnError on_error = BLOCKDEV_ON_ERROR_REPORT;
int job_flags = JOB_DEFAULT;
if (!has_speed) {
speed = 0;
}
+ if (!has_on_error) {
+ on_error = BLOCKDEV_ON_ERROR_REPORT;
+ }
if (!has_filter_node_name) {
filter_node_name = NULL;
}
--
2.20.1
^ permalink raw reply related
* Re: [PATCH 07/35] KVM: s390: add new variants of UV CALL
From: Christian Borntraeger @ 2020-02-14 20:13 UTC (permalink / raw)
To: David Hildenbrand, Janosch Frank
Cc: KVM, Cornelia Huck, Thomas Huth, Ulrich Weigand, Claudio Imbrenda,
Andrea Arcangeli, linux-s390, Michael Mueller, Vasily Gorbik,
Janosch Frank
In-Reply-To: <b9988313-74d1-6e68-efef-d012aae30d6d@redhat.com>
On 14.02.20 19:28, David Hildenbrand wrote:
> On 07.02.20 12:39, Christian Borntraeger wrote:
>> From: Janosch Frank <frankja@linux.ibm.com>
>>
>> This add 2 new variants of the UV CALL.
>>
>> The first variant handles UV CALLs that might have longer busy
>> conditions or just need longer when doing partial completion. We should
>> schedule when necessary.
>>
>> The second variant handles UV CALLs that only need the handle but have
>> no payload (e.g. destroying a VM). We can provide a simple wrapper for
>> those.
>>
>> Signed-off-by: Janosch Frank <frankja@linux.ibm.com>
>> [borntraeger@de.ibm.com: patch merging, splitting, fixing]
>> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
>> ---
>> arch/s390/include/asm/uv.h | 59 ++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 59 insertions(+)
>>
>> diff --git a/arch/s390/include/asm/uv.h b/arch/s390/include/asm/uv.h
>> index 1b97230a57ba..e1cef772fde1 100644
>> --- a/arch/s390/include/asm/uv.h
>> +++ b/arch/s390/include/asm/uv.h
>> @@ -14,6 +14,7 @@
>> #include <linux/types.h>
>> #include <linux/errno.h>
>> #include <linux/bug.h>
>> +#include <linux/sched.h>
>> #include <asm/page.h>
>> #include <asm/gmap.h>
>>
>> @@ -91,6 +92,19 @@ struct uv_cb_cfs {
>> u64 paddr;
>> } __packed __aligned(8);
>>
>> +/*
>> + * A common UV call struct for calls that take no payload
>> + * Examples:
>> + * Destroy cpu/config
>> + * Verify
>> + */
>> +struct uv_cb_nodata {
>> + struct uv_cb_header header;
>> + u64 reserved08[2];
>> + u64 handle;
>> + u64 reserved20[4];
>> +} __packed __aligned(8);
>> +
>> struct uv_cb_share {
>> struct uv_cb_header header;
>> u64 reserved08[3];
>> @@ -98,6 +112,31 @@ struct uv_cb_share {
>> u64 reserved28;
>> } __packed __aligned(8);
>>
>> +/*
>> + * Low level uv_call that takes r1 and r2 as parameter and avoids
>> + * stalls for long running busy conditions by doing schedule
>> + */
>> +static inline int uv_call_sched(unsigned long r1, unsigned long r2)
>> +{
>> + int cc;
>> +
>> + do {
>> + asm volatile(
>> + "0: .insn rrf,0xB9A40000,%[r1],%[r2],0,0\n"
>
> label not necessary
ack
>
>> + " ipm %[cc]\n"
>> + " srl %[cc],28\n"
>> + : [cc] "=d" (cc)
>> + : [r1] "d" (r1), [r2] "d" (r2)
>> + : "memory", "cc");
>
> I was wondering if we could reuse uv_call() - something like
>
> static inline int __uv_call(unsigned long r1, unsigned long r2)
> {
> int cc;
>
> asm volatile(
> " .insn rrf,0xB9A40000,%[r1],%[r2],0,0\n"
> " ipm %[cc]\n"
> " srl %[cc],28\n"
> : [cc] "=d" (cc)
> : [r1] "a" (r1), [r2] "a" (r2)
> : "memory", "cc");
> return cc;
> }
>
> static inline int uv_call(unsigned long r1, unsigned long r2)
> {
> int rc;
>
> do {
> cc = __uv_call(unsigned long r1, unsigned long r2);
> } while (cc > 1)
> return rc;
This will likely generate less efficient assembly code but it is certainly
easier to read. WIll change.
> }
>
> static inline int uv_call_sched(unsigned long r1, unsigned long r2)
> {
> int rc;
>
> do {
> cc = __uv_call(unsigned long r1, unsigned long r2);
> cond_resched();
> } while (rc > 1)
> return rc;
> }
>
>> + if (need_resched())
>> + schedule();
>
> cond_resched();
ack
>
>> + } while (cc > 1);
>> + return cc;
>> +}
>> +
>> +/*
>> + * Low level uv_call that takes r1 and r2 as parameter
>> + */
>
> This "r1 and r2" does not sound like relevant news. Same for the other
> variant above.
>
>> static inline int uv_call(unsigned long r1, unsigned long r2)
>> {
>> int cc;
>> @@ -113,6 +152,26 @@ static inline int uv_call(unsigned long r1, unsigned long r2)
>> return cc;
>> }
>>
>> +/*
>> + * special variant of uv_call that only transports the cpu or guest
>> + * handle and the command, like destroy or verify.
>> + */
>> +static inline int uv_cmd_nodata(u64 handle, u16 cmd, u32 *ret)
>
> uv_call_sched_simple() ?
I think nodata is actually a better description
^ permalink raw reply
* Re: Buffered IO async context overhead
From: Jens Axboe @ 2020-02-14 20:13 UTC (permalink / raw)
To: Andres Freund, io-uring
In-Reply-To: <20200214195030.cbnr6msktdl3tqhn@alap3.anarazel.de>
On 2/14/20 12:50 PM, Andres Freund wrote:
> Hi,
>
> For workloads where a lot of buffered IO is done, I see considerably
> higher overhead when going through io_uring, then when just doing the IO
> synchronously.
>
> This example is on a samsung 970 pro nvme (i.e. decent, but not top
> class). I've limited the amount of dirty buffers allowed to 2/4 GB to
> keep the test times in check. This is with a relatively recent kernel,
> 33b40134e5cfbbccad7f3040d1919889537a3df7 .
>
> fio --name=t --time_based=1 --runtime=100 --ioengine=io_uring --rw=write --bs=8k --filesize=300G --iodepth=1
>
> Jobs: 1 (f=1): [W(1)][100.0%][w=1049MiB/s][w=134k IOPS][eta 00m:00s]
> t: (groupid=0, jobs=1): err= 0: pid=46625: Fri Feb 14 11:22:05 2020
> write: IOPS=73.4k, BW=573MiB/s (601MB/s)(55.0GiB/100001msec); 0 zone resets
> slat (nsec): min=571, max=607779, avg=2927.18, stdev=1213.47
> clat (nsec): min=40, max=1400.7k, avg=9947.92, stdev=2606.65
> lat (usec): min=4, max=1403, avg=12.94, stdev= 3.28
> clat percentiles (nsec):
> | 1.00th=[ 4960], 5.00th=[ 6368], 10.00th=[ 8032], 20.00th=[ 8640],
> | 30.00th=[ 9024], 40.00th=[ 9280], 50.00th=[ 9664], 60.00th=[10048],
> | 70.00th=[10560], 80.00th=[11072], 90.00th=[11968], 95.00th=[13120],
> | 99.00th=[21632], 99.50th=[23424], 99.90th=[26752], 99.95th=[28288],
> | 99.99th=[35584]
> bw ( KiB/s): min=192408, max=1031483, per=79.92%, avg=468998.16, stdev=108691.70, samples=199
> iops : min=24051, max=128935, avg=58624.37, stdev=13586.54, samples=199
> lat (nsec) : 50=0.01%, 100=0.01%, 250=0.01%, 500=0.01%, 750=0.01%
> lat (nsec) : 1000=0.01%
> lat (usec) : 2=0.01%, 4=0.01%, 10=56.98%, 20=41.67%, 50=1.32%
> lat (usec) : 100=0.01%, 250=0.01%, 500=0.01%, 750=0.01%
> lat (msec) : 2=0.01%
> cpu : usr=15.63%, sys=34.79%, ctx=7333387, majf=0, minf=41
> IO depths : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
> submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
> complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
> issued rwts: total=0,7335827,0,0 short=0,0,0,0 dropped=0,0,0,0
> latency : target=0, window=0, percentile=100.00%, depth=1
>
> Run status group 0 (all jobs):
> WRITE: bw=573MiB/s (601MB/s), 573MiB/s-573MiB/s (601MB/s-601MB/s), io=55.0GiB (60.1GB), run=100001-100001msec
>
> Disk stats (read/write):
> nvme0n1: ios=0/49033, merge=0/12, ticks=0/1741787, in_queue=1717299, util=20.89%
>
>
> During this most of the time there's a number of tasks with decent CPU usage
> 46627 root 20 0 0 0 0 R 99.7 0.0 1:07.74 io_wqe_worker-0
> 46625 root 20 0 756920 6708 1984 S 51.0 0.0 0:34.56 fio
> 42818 root 20 0 0 0 0 I 3.3 0.0 0:03.23 kworker/u82:6-flush-259:0
> 43338 root 20 0 0 0 0 I 1.3 0.0 0:02.06 kworker/u82:18-events_unbound
>
>
> Comparing that to using sync:
> fio --name=t --time_based=1 --runtime=100 --ioengine=sync --rw=write --bs=8k --filesize=300G --iodepth=1
> Jobs: 1 (f=1): [W(1)][100.0%][w=1607MiB/s][w=206k IOPS][eta 00m:00s]
> t: (groupid=0, jobs=1): err= 0: pid=46690: Fri Feb 14 11:24:17 2020
> write: IOPS=234k, BW=1831MiB/s (1920MB/s)(179GiB/100001msec); 0 zone resets
> clat (nsec): min=1612, max=6649.7k, avg=3913.39, stdev=3170.65
> lat (nsec): min=1653, max=6649.7k, avg=3955.30, stdev=3172.59
> clat percentiles (nsec):
> | 1.00th=[ 2512], 5.00th=[ 2544], 10.00th=[ 2576], 20.00th=[ 2640],
> | 30.00th=[ 2672], 40.00th=[ 2768], 50.00th=[ 3376], 60.00th=[ 3792],
> | 70.00th=[ 4192], 80.00th=[ 4832], 90.00th=[ 5792], 95.00th=[ 7008],
> | 99.00th=[11968], 99.50th=[15552], 99.90th=[22656], 99.95th=[26496],
> | 99.99th=[40192]
> bw ( MiB/s): min= 989, max= 2118, per=82.26%, avg=1506.28, stdev=169.56, samples=193
> iops : min=126684, max=271118, avg=192803.37, stdev=21703.94, samples=193
> lat (usec) : 2=0.01%, 4=66.33%, 10=32.14%, 20=1.34%, 50=0.19%
> lat (usec) : 100=0.01%, 250=0.01%, 500=0.01%, 1000=0.01%
> lat (msec) : 2=0.01%, 10=0.01%
> cpu : usr=8.35%, sys=91.55%, ctx=6183, majf=0, minf=74
> IO depths : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
> submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
> complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
> issued rwts: total=0,23437892,0,0 short=0,0,0,0 dropped=0,0,0,0
> latency : target=0, window=0, percentile=100.00%, depth=1
>
> Run status group 0 (all jobs):
> WRITE: bw=1831MiB/s (1920MB/s), 1831MiB/s-1831MiB/s (1920MB/s-1920MB/s), io=179GiB (192GB), run=100001-100001msec
>
> Disk stats (read/write):
> nvme0n1: ios=0/152371, merge=0/587772, ticks=0/5657236, in_queue=5580764, util=67.57%
>
> Tasks:
> 46690 root 20 0 756912 6524 1800 R 100.0 0.0 1:24.64 fio
> 2913 root 20 0 0 0 0 S 32.2 0.0 0:09.57 kswapd1
> 45683 root 20 0 0 0 0 I 13.2 0.0 0:08.57 kworker/u82:16-events_unbound
> 42816 root 20 0 0 0 0 I 11.2 0.0 0:09.71 kworker/u82:1-flush-259:0
> 36087 root 20 0 0 0 0 I 1.6 0.0 0:01.51 kworker/27:2-xfs-conv/nvme0n1
>
> I.e. sync did about three times the throughput of io_uring.
>
>
> It's possible to make io_uring perform better, by batching
> submissions/completions:
> fio --name=t --time_based=1 --runtime=100 --ioengine=io_uring --rw=write --bs=8k --filesize=300G --iodepth=64 --iodepth_batch_submit=32 --iodepth_batch_complete_min=16 --iodepth_low=16
> t: (g=0): rw=write, bs=(R) 8192B-8192B, (W) 8192B-8192B, (T) 8192B-8192B, ioengine=io_uring, iodepth=64
> fio-3.17
> Starting 1 process
> Jobs: 1 (f=1): [W(1)][100.0%][w=1382MiB/s][w=177k IOPS][eta 00m:00s]
> t: (groupid=0, jobs=1): err= 0: pid=46849: Fri Feb 14 11:28:13 2020
> write: IOPS=194k, BW=1513MiB/s (1587MB/s)(148GiB/100001msec); 0 zone resets
> slat (usec): min=4, max=455, avg=48.09, stdev=18.20
> clat (usec): min=6, max=25435, avg=164.91, stdev=104.69
> lat (usec): min=66, max=25512, avg=213.03, stdev=101.19
> clat percentiles (usec):
> | 1.00th=[ 60], 5.00th=[ 68], 10.00th=[ 78], 20.00th=[ 94],
> | 30.00th=[ 108], 40.00th=[ 127], 50.00th=[ 143], 60.00th=[ 180],
> | 70.00th=[ 210], 80.00th=[ 227], 90.00th=[ 265], 95.00th=[ 302],
> | 99.00th=[ 379], 99.50th=[ 441], 99.90th=[ 562], 99.95th=[ 611],
> | 99.99th=[ 816]
> bw ( MiB/s): min= 289, max= 1802, per=81.00%, avg=1225.72, stdev=173.92, samples=197
> iops : min=37086, max=230692, avg=156891.42, stdev=22261.80, samples=197
> lat (usec) : 10=0.01%, 50=0.09%, 100=25.74%, 250=60.50%, 500=13.46%
> lat (usec) : 750=0.19%, 1000=0.01%
> lat (msec) : 2=0.01%, 10=0.01%, 20=0.01%, 50=0.01%
> cpu : usr=31.80%, sys=26.04%, ctx=793383, majf=0, minf=1301
> IO depths : 1=0.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=66.7%, >=64=33.3%
> submit : 0=0.0%, 4=0.0%, 8=0.0%, 16=50.0%, 32=50.0%, 64=0.0%, >=64=0.0%
> complete : 0=0.0%, 4=0.0%, 8=0.0%, 16=100.0%, 32=0.1%, 64=0.0%, >=64=0.0%
> issued rwts: total=0,19369087,0,0 short=0,0,0,0 dropped=0,0,0,0
> latency : target=0, window=0, percentile=100.00%, depth=64
>
> Run status group 0 (all jobs):
> WRITE: bw=1513MiB/s (1587MB/s), 1513MiB/s-1513MiB/s (1587MB/s-1587MB/s), io=148GiB (159GB), run=100001-100001msec
>
> Disk stats (read/write):
> nvme0n1: ios=0/127095, merge=0/15, ticks=0/4936953, in_queue=4873341, util=55.82%
>
> but that's still worse than the plain sync one. And doesn't work well
> for reads.
>
>
> Now, it's clear that there's some overhead in backgrounding small IOs to
> the async context, but this seems awfully high. There's still a slowdown
> when using considerably larger pieces of IO (128k).
>
> For the 128k, iodepth 1 case I get:
> sync:
> - 97.77% 0.04% fio fio [.] fio_syncio_queue
> 97.73% fio_syncio_queue
> - __libc_write
> - __libc_write
> - 97.50% entry_SYSCALL_64
> - 97.31% do_syscall_64
> - 97.25% ksys_write
> - 97.10% vfs_write
> - 96.91% new_sync_write
> - 96.82% xfs_file_buffered_aio_write
> - 96.13% iomap_file_buffered_write
> - iomap_apply
> - 95.52% iomap_write_actor
> + 37.66% iov_iter_copy_from_user_atomic
> + 26.83% iomap_write_begin
> + 26.64% iomap_write_end.isra.0
> 2.26% iov_iter_fault_in_readable
> 0.87% balance_dirty_pages_ratelimited
> and --no-children shows:
> + 36.57% fio [kernel.vmlinux] [k] copy_user_enhanced_fast_string
> + 14.31% fio [kernel.vmlinux] [k] iomap_set_range_uptodate
> + 3.85% fio [kernel.vmlinux] [k] get_page_from_freelist
> + 3.34% fio [kernel.vmlinux] [k] queued_spin_lock_slowpath
> + 2.94% fio [kernel.vmlinux] [k] xas_load
> + 2.66% fio [kernel.vmlinux] [k] __add_to_page_cache_locked
> + 2.51% fio [kernel.vmlinux] [k] _raw_spin_lock_irqsave
> + 2.28% fio [kernel.vmlinux] [k] iov_iter_fault_in_readable
> + 1.87% fio [kernel.vmlinux] [k] __lru_cache_add
> + 1.80% fio [kernel.vmlinux] [k] __pagevec_lru_add_fn
> + 1.59% fio [kernel.vmlinux] [k] node_dirty_ok
> + 1.30% fio [kernel.vmlinux] [k] _raw_spin_lock_irq
> + 1.30% fio [kernel.vmlinux] [k] iomap_set_page_dirty
> + 1.25% fio fio [.] get_io_u
> + 1.18% fio [kernel.vmlinux] [k] xas_start
>
> io_uring (the io_wqe_worker-0):
> - 100.00% 22.64% io_wqe_worker-0 [kernel.vmlinux] [k] io_wqe_worker
> - 77.36% io_wqe_worker
> - 77.18% io_worker_handle_work
> - 75.80% io_rw_async
> - io_wq_submit_work
> - 75.57% io_issue_sqe
> - io_write
> - 70.96% xfs_file_buffered_aio_write
> - 70.37% iomap_file_buffered_write
> - iomap_apply
> - 70.08% iomap_write_actor
> + 30.05% iov_iter_copy_from_user_atomic
> - 18.38% iomap_write_begin
> - 17.64% grab_cache_page_write_begin
> + 16.73% pagecache_get_page
> 0.51% wait_for_stable_page
> - 16.96% iomap_write_end.isra.0
> 8.72% iomap_set_range_uptodate
> + 7.35% iomap_set_page_dirty
> 3.45% iov_iter_fault_in_readable
> 0.56% balance_dirty_pages_ratelimited
> - 4.36% kiocb_done
> - 3.56% io_cqring_ev_posted
> + __wake_up_common_lock
> 0.61% io_cqring_add_event
> 0.56% io_free_req
> --no-children:
> + 29.55% io_wqe_worker-0 [kernel.vmlinux] [k] copy_user_enhanced_fast_string
> + 22.64% io_wqe_worker-0 [kernel.vmlinux] [k] io_wqe_worker
> + 8.71% io_wqe_worker-0 [kernel.vmlinux] [k] iomap_set_range_uptodate
> + 3.41% io_wqe_worker-0 [kernel.vmlinux] [k] iov_iter_fault_in_readable
> + 2.50% io_wqe_worker-0 [kernel.vmlinux] [k] get_page_from_freelist
> + 2.24% io_wqe_worker-0 [kernel.vmlinux] [k] xas_load
> + 1.82% io_wqe_worker-0 [kernel.vmlinux] [k] queued_spin_lock_slowpath
> + 1.80% io_wqe_worker-0 [kernel.vmlinux] [k] _raw_spin_lock_irqsave
> + 1.72% io_wqe_worker-0 [kernel.vmlinux] [k] __add_to_page_cache_locked
> + 1.58% io_wqe_worker-0 [kernel.vmlinux] [k] _raw_spin_lock_irq
> + 1.29% io_wqe_worker-0 [kernel.vmlinux] [k] __lru_cache_add
> + 1.27% io_wqe_worker-0 [kernel.vmlinux] [k] __pagevec_lru_add_fn
> + 1.08% io_wqe_worker-0 [kernel.vmlinux] [k] xas_start
>
> So it seems the biggest difference is the cpu time in io_wqe_worker
> itself. Which in turn appears to mostly be:
>
> │ mov %rbp,%rdi
> │ → callq io_worker_handle_work
> │ mov $0x3e7,%eax
> │ ↓ jmp 28c
> │ rep_nop():
> │ }
> │
> │ /* REP NOP (PAUSE) is a good thing to insert into busy-wait loops. */
> │ static __always_inline void rep_nop(void)
> │ {
> │ asm volatile("rep; nop" ::: "memory");
> 74.50 │281: pause
> │ io_worker_spin_for_work():
> │ while (++i < 1000) {
> 11.15 │ sub $0x1,%eax
> │ ↑ je 9b
> │ __read_once_size():
> │ __READ_ONCE_SIZE;
> 9.53 │28c: mov 0x8(%rbx),%rdx
> │ io_wqe_run_queue():
> │ if (!wq_list_empty(&wqe->work_list) &&
> │ test %rdx,%rdx
> 2.68 │ ↓ je 29f
> │ io_worker_spin_for_work():
>
>
> With 8k it looks similar, but more extreme:
> sync (fio itself):
> + 29.89% fio [kernel.vmlinux] [k] copy_user_enhanced_fast_string
> + 14.10% fio [kernel.vmlinux] [k] iomap_set_range_uptodate
> + 2.80% fio [kernel.vmlinux] [k] get_page_from_freelist
> + 2.66% fio [kernel.vmlinux] [k] queued_spin_lock_slowpath
> + 2.46% fio [kernel.vmlinux] [k] xas_load
> + 1.97% fio [kernel.vmlinux] [k] _raw_spin_lock_irqsave
> + 1.94% fio [kernel.vmlinux] [k] __add_to_page_cache_locked
> + 1.79% fio [kernel.vmlinux] [k] iomap_set_page_dirty
> + 1.64% fio [kernel.vmlinux] [k] iov_iter_fault_in_readable
> + 1.61% fio fio [.] __fio_gettime
> + 1.49% fio [kernel.vmlinux] [k] __pagevec_lru_add_fn
> + 1.39% fio [kernel.vmlinux] [k] __lru_cache_add
> 1.30% fio fio [.] get_io_u
> + 1.11% fio [kernel.vmlinux] [k] up_write
> + 1.10% fio [kernel.vmlinux] [k] node_dirty_ok
> + 1.09% fio [kernel.vmlinux] [k] down_write
>
> io_uring (io_wqe_worker-0 again):
> + 54.13% io_wqe_worker-0 [kernel.vmlinux] [k] io_wqe_worker
> + 11.01% io_wqe_worker-0 [kernel.vmlinux] [k] copy_user_enhanced_fast_string
> + 2.70% io_wqe_worker-0 [kernel.vmlinux] [k] iomap_set_range_uptodate
> + 2.62% io_wqe_worker-0 [kernel.vmlinux] [k] iov_iter_fault_in_readable
> + 1.91% io_wqe_worker-0 [kernel.vmlinux] [k] __slab_free
> + 1.85% io_wqe_worker-0 [kernel.vmlinux] [k] _raw_spin_lock_irqsave
> + 1.66% io_wqe_worker-0 [kernel.vmlinux] [k] try_to_wake_up
> + 1.62% io_wqe_worker-0 [kernel.vmlinux] [k] io_cqring_fill_event
> + 1.55% io_wqe_worker-0 [kernel.vmlinux] [k] io_rw_async
> + 1.43% io_wqe_worker-0 [kernel.vmlinux] [k] __wake_up_common
> + 1.37% io_wqe_worker-0 [kernel.vmlinux] [k] _raw_spin_lock_irq
> + 1.20% io_wqe_worker-0 [kernel.vmlinux] [k] rw_verify_area
>
> 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)
--
Jens Axboe
^ permalink raw reply related
* Re: [PATCH 00/19] target/arm: vfp feature and decodetree cleanup
From: no-reply @ 2020-02-14 20:11 UTC (permalink / raw)
To: richard.henderson; +Cc: peter.maydell, qemu-devel
In-Reply-To: <20200214181547.21408-1-richard.henderson@linaro.org>
Patchew URL: https://patchew.org/QEMU/20200214181547.21408-1-richard.henderson@linaro.org/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Subject: [PATCH 00/19] target/arm: vfp feature and decodetree cleanup
Message-id: 20200214181547.21408-1-richard.henderson@linaro.org
Type: series
=== TEST SCRIPT BEGIN ===
#!/bin/bash
git rev-parse base > /dev/null || exit 0
git config --local diff.renamelimit 0
git config --local diff.renames True
git config --local diff.algorithm histogram
./scripts/checkpatch.pl --mailback base..
=== TEST SCRIPT END ===
From https://github.com/patchew-project/qemu
* [new tag] patchew/20200214181547.21408-1-richard.henderson@linaro.org -> patchew/20200214181547.21408-1-richard.henderson@linaro.org
Switched to a new branch 'test'
95783b0 target/arm: Split VMINMAXNM decode
767538b target/arm: Split VFM decode
f42df4d target/arm: Add formats for some vfp 2 and 3-register insns
7ab67bb target/arm: Remove ARM_FEATURE_VFP*
1666ad9 linux-user/arm: Replace ARM_FEATURE_VFP* tests for HWCAP
65ff809 target/arm: Move the vfp decodetree calls next to the base isa
869a0c6 target/arm: Move VLLDM and VLSTM to vfp.decode
5f4493e target/arm: Remove ARM_FEATURE_VFP check from disas_vfp_insn
4de9678 target/arm: Replace ARM_FEATURE_VFP4 with isar_feature_aa32_simdfmac
18e3a45 target/arm: Add missing checks for fpsp_v2
7308009 target/arm: Replace ARM_FEATURE_VFP3 checks with fp{sp, dp}_v3
9a14898 target/arm: Perform fpdp_v2 check first
cf0d4dd target/arm: Add isar_feature_aa32_{fpsp_v2, fpsp_v3, fpdp_v3}
ee3781d target/arm: Rename isar_feature_aa32_fpdp_v2
0620ff1 target/arm: Add isar_feature_aa32_simd_r16
c4a4615 target/arm: Set MVFR0.FPSP for ARMv5 cpus
0ad6da0 target/arm: Use isar_feature_aa32_simd_r32 more places
ea58091 target/arm: Rename isar_feature_aa32_simd_r32
fdabf89 target/arm: Fix field extract from MVFR[0-2]
=== OUTPUT BEGIN ===
1/19 Checking commit fdabf896edb9 (target/arm: Fix field extract from MVFR[0-2])
2/19 Checking commit ea5809173fd7 (target/arm: Rename isar_feature_aa32_simd_r32)
WARNING: line over 80 characters
#143: FILE: target/arm/translate-vfp.inc.c:1825:
+ if (!dc_isar_feature(aa32_simd_r32, s) && ((a->vd | a->vn | a->vm) & 0x10)) {
total: 0 errors, 1 warnings, 216 lines checked
Patch 2/19 has style problems, please review. If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
3/19 Checking commit 0ad6da01bb17 (target/arm: Use isar_feature_aa32_simd_r32 more places)
4/19 Checking commit c4a4615631d0 (target/arm: Set MVFR0.FPSP for ARMv5 cpus)
5/19 Checking commit 0620ff1eeadf (target/arm: Add isar_feature_aa32_simd_r16)
6/19 Checking commit ee3781d87d37 (target/arm: Rename isar_feature_aa32_fpdp_v2)
7/19 Checking commit cf0d4dd72bc1 (target/arm: Add isar_feature_aa32_{fpsp_v2, fpsp_v3, fpdp_v3})
8/19 Checking commit 9a14898afce1 (target/arm: Perform fpdp_v2 check first)
9/19 Checking commit 7308009078c7 (target/arm: Replace ARM_FEATURE_VFP3 checks with fp{sp, dp}_v3)
10/19 Checking commit 18e3a454c82a (target/arm: Add missing checks for fpsp_v2)
11/19 Checking commit 4de967840769 (target/arm: Replace ARM_FEATURE_VFP4 with isar_feature_aa32_simdfmac)
12/19 Checking commit 5f4493e01033 (target/arm: Remove ARM_FEATURE_VFP check from disas_vfp_insn)
13/19 Checking commit 869a0c6ea3c9 (target/arm: Move VLLDM and VLSTM to vfp.decode)
14/19 Checking commit 65ff809853db (target/arm: Move the vfp decodetree calls next to the base isa)
ERROR: trailing whitespace
#106: FILE: target/arm/translate.c:10663:
+ * Note disas_vfp is written for a32 with cond field in the $
total: 1 errors, 0 warnings, 128 lines checked
Patch 14/19 has style problems, please review. If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
15/19 Checking commit 1666ad9ed1e2 (linux-user/arm: Replace ARM_FEATURE_VFP* tests for HWCAP)
16/19 Checking commit 7ab67bbe6345 (target/arm: Remove ARM_FEATURE_VFP*)
17/19 Checking commit f42df4d1f1aa (target/arm: Add formats for some vfp 2 and 3-register insns)
18/19 Checking commit 767538ba7ae0 (target/arm: Split VFM decode)
19/19 Checking commit 95783b0b4fd0 (target/arm: Split VMINMAXNM decode)
=== OUTPUT END ===
Test command exited with code: 1
The full log is available at
http://patchew.org/logs/20200214181547.21408-1-richard.henderson@linaro.org/testing.checkpatch/?type=message.
---
Email generated automatically by Patchew [https://patchew.org/].
Please send your feedback to patchew-devel@redhat.com
^ permalink raw reply
* [igt-dev] ✗ GitLab.Pipeline: failure for series starting with [i-g-t,1/4] i915/gem_ctx_engines: Exercise 0 engines[]
From: Patchwork @ 2020-02-14 20:13 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 : failure
== Summary ==
ERROR! This series introduces new undocumented tests:
gem_ctx_engines@libapi
gem_ctx_engines@none
Can you document them as per the requirement in the [CONTRIBUTING.md]?
[Documentation] has more details on how to do this.
Here are few examples:
https://gitlab.freedesktop.org/drm/igt-gpu-tools/commit/0316695d03aa46108296b27f3982ec93200c7a6e
https://gitlab.freedesktop.org/drm/igt-gpu-tools/commit/443cc658e1e6b492ee17bf4f4d891029eb7a205d
Thanks in advance!
[CONTRIBUTING.md]: https://gitlab.freedesktop.org/drm/igt-gpu-tools/blob/master/CONTRIBUTING.md#L19
[Documentation]: https://drm.pages.freedesktop.org/igt-gpu-tools/igt-gpu-tools-Core.html#igt-describe
Other than that, pipeline status: SUCCESS.
see https://gitlab.freedesktop.org/gfx-ci/igt-ci-tags/pipelines/108865 for the overview.
== Logs ==
For more details see: https://gitlab.freedesktop.org/gfx-ci/igt-ci-tags/pipelines/108865
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev
^ permalink raw reply
* [PATCH 3/7] commit: Fix argument order for block_job_error_action()
From: Kevin Wolf @ 2020-02-14 20:08 UTC (permalink / raw)
To: qemu-block; +Cc: kwolf, pkrempa, qemu-devel, mreitz, nsoffer, jsnow
In-Reply-To: <20200214200812.28180-1-kwolf@redhat.com>
The block_job_error_action() error call in the commit job gives the
on_err and is_read arguments in the wrong order. Fix this.
(Of course, hard-coded is_read = false is wrong, too, but that's a
separate problem for a separate patch.)
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
---
block/commit.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/block/commit.c b/block/commit.c
index cce898a4f3..8189f079d2 100644
--- a/block/commit.c
+++ b/block/commit.c
@@ -182,7 +182,7 @@ static int coroutine_fn commit_run(Job *job, Error **errp)
}
if (ret < 0) {
BlockErrorAction action =
- block_job_error_action(&s->common, false, s->on_error, -ret);
+ block_job_error_action(&s->common, s->on_error, false, -ret);
if (action == BLOCK_ERROR_ACTION_REPORT) {
goto out;
} else {
--
2.20.1
^ permalink raw reply related
* Re: [PATCH 4.19 091/195] padata: Remove broken queue flushing
From: Daniel Jordan @ 2020-02-14 20:10 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Yang Yingliang, linux-kernel, stable, Herbert Xu, Daniel Jordan,
Sasha Levin
In-Reply-To: <20200214152128.GC3959278@kroah.com>
On Fri, Feb 14, 2020 at 07:21:28AM -0800, Greg Kroah-Hartman wrote:
> So this causes a problem in the 4.19-rc tree but not in Linus's tree?
> Or am I confused? Should it be dropped from stable or is there some
> other fix-of-a-fix that I need to apply here?
This causes a problem in 4.19.103 and 4.19-rc but not Linus's tree.
The fix-of-a-fix is posted recently here:
https://lore.kernel.org/lkml/20200214182821.337706-1-daniel.m.jordan@oracle.com/
For 4.14, 4.9, and 4.4, I'm posting a revised version of "Remove broken queue
flushing" in each review thread. 4.14 is already up. Is this what I should be
doing?
thanks,
Daniel
^ permalink raw reply
* Re: [PATCH v5 2/3] usb: dwc3: qcom: Add interconnect support in dwc3 driver
From: Matthias Kaehlcke @ 2020-02-14 20:11 UTC (permalink / raw)
To: Sandeep Maheswaram
Cc: Andy Gross, Bjorn Andersson, Greg Kroah-Hartman, Rob Herring,
Mark Rutland, Felipe Balbi, Stephen Boyd, Doug Anderson,
linux-arm-msm, linux-usb, devicetree, linux-kernel, Manu Gautam,
Chandana Kishori Chiluveru
In-Reply-To: <1581668684-4182-3-git-send-email-sanm@codeaurora.org>
Hi Sandeep,
On Fri, Feb 14, 2020 at 01:54:43PM +0530, Sandeep Maheswaram wrote:
> Add interconnect support in dwc3-qcom driver to vote for bus
> bandwidth.
>
> This requires for two different paths - from USB master to
> DDR slave. The other is from APPS master to USB slave.
>
> Signed-off-by: Sandeep Maheswaram <sanm@codeaurora.org>
> Signed-off-by: Chandana Kishori Chiluveru <cchiluve@codeaurora.org>
> ---
> drivers/usb/dwc3/dwc3-qcom.c | 135 ++++++++++++++++++++++++++++++++++++++++++-
> 1 file changed, 133 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/usb/dwc3/dwc3-qcom.c b/drivers/usb/dwc3/dwc3-qcom.c
> index 261af9e..2ed6c20 100644
> --- a/drivers/usb/dwc3/dwc3-qcom.c
> +++ b/drivers/usb/dwc3/dwc3-qcom.c
> @@ -13,6 +13,7 @@
> #include <linux/module.h>
> #include <linux/kernel.h>
> #include <linux/extcon.h>
> +#include <linux/interconnect.h>
> #include <linux/of_platform.h>
> #include <linux/platform_device.h>
> #include <linux/phy/phy.h>
> @@ -43,6 +44,14 @@
> #define SDM845_QSCRATCH_SIZE 0x400
> #define SDM845_DWC3_CORE_SIZE 0xcd00
>
> +/* Interconnect path bandwidths in MBps */
> +#define USB_MEMORY_AVG_HS_BW MBps_to_icc(240)
> +#define USB_MEMORY_PEAK_HS_BW MBps_to_icc(700)
> +#define USB_MEMORY_AVG_SS_BW MBps_to_icc(1000)
> +#define USB_MEMORY_PEAK_SS_BW MBps_to_icc(2500)
> +#define APPS_USB_AVG_BW 0
> +#define APPS_USB_PEAK_BW MBps_to_icc(40)
> +
> struct dwc3_acpi_pdata {
> u32 qscratch_base_offset;
> u32 qscratch_base_size;
> @@ -76,8 +85,13 @@ struct dwc3_qcom {
> enum usb_dr_mode mode;
> bool is_suspended;
> bool pm_suspended;
> + struct icc_path *usb_ddr_icc_path;
> + struct icc_path *apps_usb_icc_path;
> };
>
> +static int dwc3_qcom_interconnect_enable(struct dwc3_qcom *qcom);
> +static int dwc3_qcom_interconnect_disable(struct dwc3_qcom *qcom);
> +
> static inline void dwc3_qcom_setbits(void __iomem *base, u32 offset, u32 val)
> {
> u32 reg;
> @@ -239,7 +253,7 @@ static void dwc3_qcom_enable_interrupts(struct dwc3_qcom *qcom)
> static int dwc3_qcom_suspend(struct dwc3_qcom *qcom)
> {
> u32 val;
> - int i;
> + int i, ret;
>
> if (qcom->is_suspended)
> return 0;
> @@ -251,6 +265,10 @@ static int dwc3_qcom_suspend(struct dwc3_qcom *qcom)
> for (i = qcom->num_clocks - 1; i >= 0; i--)
> clk_disable_unprepare(qcom->clks[i]);
>
> + ret = dwc3_qcom_interconnect_disable(qcom);
> + if (ret)
> + dev_warn(qcom->dev, "failed to disable interconnect %d\n", ret);
> +
This assumes that all QCA systems with a DWC3 have an interconnect
configuration, however after applying this series SDM845 is the only
platform. You need to track somewhere if the controller in question has
an ICC config for not.
> qcom->is_suspended = true;
> dwc3_qcom_enable_interrupts(qcom);
>
> @@ -276,6 +294,10 @@ static int dwc3_qcom_resume(struct dwc3_qcom *qcom)
> }
> }
>
> + ret = dwc3_qcom_interconnect_enable(qcom);
> + if (ret)
> + dev_warn(qcom->dev, "failed to enable interconnect %d\n", ret);
> +
same as above
> /* Clear existing events from PHY related to L2 in/out */
> dwc3_qcom_setbits(qcom->qscratch_base, PWR_EVNT_IRQ_STAT_REG,
> PWR_EVNT_LPM_IN_L2_MASK | PWR_EVNT_LPM_OUT_L2_MASK);
> @@ -285,6 +307,108 @@ static int dwc3_qcom_resume(struct dwc3_qcom *qcom)
> return 0;
> }
>
> +
> +/**
> + * dwc3_qcom_interconnect_init() - Get interconnect path handles
> + * @qcom: Pointer to the concerned usb core.
> + *
> + */
> +static int dwc3_qcom_interconnect_init(struct dwc3_qcom *qcom)
> +{
> + struct device *dev = qcom->dev;
> + int ret;
> +
> + if (!device_is_bound(&qcom->dwc3->dev))
> + return -EPROBE_DEFER;
> +
> + qcom->usb_ddr_icc_path = of_icc_get(dev, "usb-ddr");
> + if (IS_ERR(qcom->usb_ddr_icc_path)) {
> + dev_err(dev, "Error: (%ld) failed getting usb-ddr path\n",
> + PTR_ERR(qcom->usb_ddr_icc_path));
> + return PTR_ERR(qcom->usb_ddr_icc_path);
> + }
This will break all QCA platforms with DWC3, except SDM845. Instead of
failing you could interpret the basence of the 'usb-ddr' patch in the DT
as signal that the controller has no ICC configuration, and continue without
it (i.e. return 0 from here, don't print an error, at most a dev_info() log),
and track somewhere that the controller has no ICC config.
Alternatively you could check above with of_find_property() whether the
controller has an 'interconnects' property at all. If it doesn't exist
return zero, otherwise return an error if any of the paths doesn't exist,
as you do now.
> +
> + qcom->apps_usb_icc_path = of_icc_get(dev, "apps-usb");
> + if (IS_ERR(qcom->apps_usb_icc_path)) {
> + dev_err(dev, "Error: (%ld) failed getting apps-usb path\n",
> + PTR_ERR(qcom->apps_usb_icc_path));
> + return PTR_ERR(qcom->apps_usb_icc_path);
> + }
Failing here is ok, if 'usb-ddr' exists, we expect the rest of the config
to be in place.
> +
> + ret = dwc3_qcom_interconnect_enable(qcom);
> + if (ret) {
> + dev_err(dev, "failed to enable interconnect %d\n", ret);
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> +/**
> + * dwc3_qcom_interconnect_exit() - Release interconnect path handles
> + * @qcom: Pointer to the concerned usb core.
> + *
> + * This function is used to release interconnect path handle.
> + */
> +static void dwc3_qcom_interconnect_exit(struct dwc3_qcom *qcom)
> +{
> + icc_put(qcom->usb_ddr_icc_path);
> + icc_put(qcom->apps_usb_icc_path);
> +}
> +
> +/* Currently we only use bandwidth level, so just "enable" interconnects */
> +static int dwc3_qcom_interconnect_enable(struct dwc3_qcom *qcom)
> +{
> + struct dwc3 *dwc = platform_get_drvdata(qcom->dwc3);
> + int ret;
> +
> + if (dwc->maximum_speed == USB_SPEED_SUPER) {
> + ret = icc_set_bw(qcom->usb_ddr_icc_path,
> + USB_MEMORY_AVG_SS_BW, USB_MEMORY_PEAK_SS_BW);
> + } else {
> + ret = icc_set_bw(qcom->usb_ddr_icc_path,
> + USB_MEMORY_AVG_HS_BW, USB_MEMORY_PEAK_HS_BW);
> + }
nit: curly braces are not needed here
> +
> + if (ret)
> + return ret;
> +
> + ret = icc_set_bw(qcom->apps_usb_icc_path,
> + APPS_USB_AVG_BW, APPS_USB_PEAK_BW);
> + if (ret)
> + icc_set_bw(qcom->usb_ddr_icc_path, 0, 0);
> +
> + return ret;
> +}
> +
> +/* To disable an interconnect, we just set its bandwidth to 0 */
> +static int dwc3_qcom_interconnect_disable(struct dwc3_qcom *qcom)
> +{
> + struct dwc3 *dwc = platform_get_drvdata(qcom->dwc3);
> + int ret;
> +
> + ret = icc_set_bw(qcom->usb_ddr_icc_path, 0, 0);
> + if (ret)
> + return ret;
> +
> + ret = icc_set_bw(qcom->apps_usb_icc_path, 0, 0);
> + if (ret)
> + goto err_reenable_memory_path;
> +
> + return 0;
> +
> + /* Re-enable things in the event of an error */
> +err_reenable_memory_path:
> + if (dwc->maximum_speed == USB_SPEED_SUPER)
> + icc_set_bw(qcom->usb_ddr_icc_path,
> + USB_MEMORY_AVG_SS_BW, USB_MEMORY_PEAK_SS_BW);
> + else
> + icc_set_bw(qcom->usb_ddr_icc_path,
> + USB_MEMORY_AVG_HS_BW, USB_MEMORY_PEAK_HS_BW);
instead of the above:
dwc3_qcom_interconnect_enable(qcom);
> +
> + return ret;
> +}
> +
> static irqreturn_t qcom_dwc3_resume_irq(int irq, void *data)
> {
> struct dwc3_qcom *qcom = data;
> @@ -648,6 +772,10 @@ static int dwc3_qcom_probe(struct platform_device *pdev)
> goto depopulate;
> }
>
> + ret = dwc3_qcom_interconnect_init(qcom);
> + if (ret)
> + goto depopulate;
> +
> qcom->mode = usb_get_dr_mode(&qcom->dwc3->dev);
>
> /* enable vbus override for device mode */
> @@ -657,7 +785,7 @@ static int dwc3_qcom_probe(struct platform_device *pdev)
> /* register extcon to override sw_vbus on Vbus change later */
> ret = dwc3_qcom_register_extcon(qcom);
> if (ret)
> - goto depopulate;
> + goto interconnect_exit;
>
> device_init_wakeup(&pdev->dev, 1);
> qcom->is_suspended = false;
> @@ -667,6 +795,8 @@ static int dwc3_qcom_probe(struct platform_device *pdev)
>
> return 0;
>
> +interconnect_exit:
> + dwc3_qcom_interconnect_exit(qcom);
> depopulate:
> if (np)
> of_platform_depopulate(&pdev->dev);
> @@ -697,6 +827,7 @@ static int dwc3_qcom_remove(struct platform_device *pdev)
> }
> qcom->num_clocks = 0;
>
> + dwc3_qcom_interconnect_exit(qcom);
> reset_control_assert(qcom->resets);
>
> pm_runtime_allow(dev);
> --
> QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
> of Code Aurora Forum, hosted by The Linux Foundation
>
^ permalink raw reply
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.