* Re: [PATCH 4/4] locking: Add kselftests for ww_mutex stress
From: Chris Wilson @ 2016-11-30 12:52 UTC (permalink / raw)
To: Maarten Lankhorst; +Cc: linux-kernel, Peter Zijlstra, Nicolai Hähnle
In-Reply-To: <67628c55-e8a1-cc33-f99a-ec458c83657c@mblankhorst.nl>
On Wed, Nov 30, 2016 at 01:29:39PM +0100, Maarten Lankhorst wrote:
> > +static void stress_work(struct work_struct *work)
> > +{
> > + struct stress *stress = container_of(work, typeof(*stress), work);
> > + const int nlocks = stress->nlocks;
> > + struct ww_mutex *locks = stress->locks;
> > + struct ww_acquire_ctx ctx;
> > + int contended = -1;
> > + int *order;
> > + int n, ret;
> > +
> > + order = get_random_order(nlocks);
> > + if (!order)
> > + return;
> > +
> > + ww_acquire_init(&ctx, &ww_class);
> > +
> > +retry:
> > + ret = 0;
> > + for (n = 0; n < nlocks; n++) {
> > + if (n == contended)
> > + continue;
> > +
> > + ret = ww_mutex_lock(&locks[order[n]], &ctx);
> > + if (ret < 0)
> > + break;
> > + }
> What's wrong with attempting to lock the contended lock here?
> Who knows, this might find some more bugs than the functional tests already do.
I was trying to follow the guide, which was lock, backoff by unlocking
everything, slowlock the contended lock, then lock everything else.
I have now a second worker that follows the reordering method as well.
(As well as a test that slowlock after the ABBA deadlock detection
resolves the locking order.)
If you have a sketch of something else to try, I'll add it.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
^ permalink raw reply
* Re: [PATCH 2/2 v2] sched: use load_avg for selecting idlest group
From: Morten Rasmussen @ 2016-11-30 12:49 UTC (permalink / raw)
To: Vincent Guittot
Cc: peterz, mingo, linux-kernel, matt, dietmar.eggemann, kernellwp,
yuyang.du, umgwanakikbuti
In-Reply-To: <1480088073-11642-3-git-send-email-vincent.guittot@linaro.org>
On Fri, Nov 25, 2016 at 04:34:33PM +0100, Vincent Guittot wrote:
> find_idlest_group() only compares the runnable_load_avg when looking for
> the least loaded group. But on fork intensive use case like hackbench
> where tasks blocked quickly after the fork, this can lead to selecting the
> same CPU instead of other CPUs, which have similar runnable load but a
> lower load_avg.
>
> When the runnable_load_avg of 2 CPUs are close, we now take into account
> the amount of blocked load as a 2nd selection factor. There is now 3 zones
> for the runnable_load of the rq:
> -[0 .. (runnable_load - imbalance)] : Select the new rq which has
> significantly less runnable_load
> -](runnable_load - imbalance) .. (runnable_load + imbalance)[ : The
> runnable load are close so we use load_avg to chose between the 2 rq
> -[(runnable_load + imbalance) .. ULONG_MAX] : Keep the current rq which
> has significantly less runnable_load
>
> For use case like hackbench, this enable the scheduler to select different
> CPUs during the fork sequence and to spread tasks across the system.
>
> Tests have been done on a Hikey board (ARM based octo cores) for several
> kernel. The result below gives min, max, avg and stdev values of 18 runs
> with each configuration.
>
> The v4.8+patches configuration also includes the changes below which is
> part of the proposal made by Peter to ensure that the clock will be up to
> date when the fork task will be attached to the rq.
>
> @@ -2568,6 +2568,7 @@ void wake_up_new_task(struct task_struct *p)
> __set_task_cpu(p, select_task_rq(p, task_cpu(p), SD_BALANCE_FORK, 0));
> #endif
> rq = __task_rq_lock(p, &rf);
> + update_rq_clock(rq);
> post_init_entity_util_avg(&p->se);
>
> activate_task(rq, p, 0);
>
> hackbench -P -g 1
>
> ea86cb4b7621 7dc603c9028e v4.8 v4.8+patches
> min 0.049 0.050 0.051 0,048
> avg 0.057 0.057(0%) 0.057(0%) 0,055(+5%)
> max 0.066 0.068 0.070 0,063
> stdev +/-9% +/-9% +/-8% +/-9%
>
> Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>
> ---
>
> Changes since v2:
> - Rebase on latest sched/core
> - Get same results with the rebase and the fix mentioned in patch 01
>
> kernel/sched/fair.c | 48 ++++++++++++++++++++++++++++++++++++++----------
> 1 file changed, 38 insertions(+), 10 deletions(-)
>
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 820a787..ecb5ee8 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -5395,16 +5395,20 @@ find_idlest_group(struct sched_domain *sd, struct task_struct *p,
> {
> struct sched_group *idlest = NULL, *group = sd->groups;
> struct sched_group *most_spare_sg = NULL;
> - unsigned long min_load = ULONG_MAX, this_load = 0;
> + unsigned long min_runnable_load = ULONG_MAX, this_runnable_load = 0;
> + unsigned long min_avg_load = ULONG_MAX, this_avg_load = 0;
> unsigned long most_spare = 0, this_spare = 0;
> int load_idx = sd->forkexec_idx;
> - int imbalance = 100 + (sd->imbalance_pct-100)/2;
> + int imbalance_scale = 100 + (sd->imbalance_pct-100)/2;
> + unsigned long imbalance = scale_load_down(NICE_0_LOAD) *
> + (sd->imbalance_pct-100) / 100;
>
> if (sd_flag & SD_BALANCE_WAKE)
> load_idx = sd->wake_idx;
>
> do {
> - unsigned long load, avg_load, spare_cap, max_spare_cap;
> + unsigned long load, avg_load, runnable_load;
> + unsigned long spare_cap, max_spare_cap;
> int local_group;
> int i;
>
> @@ -5421,6 +5425,7 @@ find_idlest_group(struct sched_domain *sd, struct task_struct *p,
> * the group containing the CPU with most spare capacity.
> */
> avg_load = 0;
> + runnable_load = 0;
> max_spare_cap = 0;
>
> for_each_cpu(i, sched_group_cpus(group)) {
> @@ -5430,7 +5435,9 @@ find_idlest_group(struct sched_domain *sd, struct task_struct *p,
> else
> load = target_load(i, load_idx);
>
> - avg_load += load;
> + runnable_load += load;
> +
> + avg_load += cfs_rq_load_avg(&cpu_rq(i)->cfs);
>
> spare_cap = capacity_spare_wake(i, p);
>
> @@ -5439,14 +5446,32 @@ find_idlest_group(struct sched_domain *sd, struct task_struct *p,
> }
>
> /* Adjust by relative CPU capacity of the group */
> - avg_load = (avg_load * SCHED_CAPACITY_SCALE) / group->sgc->capacity;
> + avg_load = (avg_load * SCHED_CAPACITY_SCALE) /
> + group->sgc->capacity;
> + runnable_load = (runnable_load * SCHED_CAPACITY_SCALE) /
> + group->sgc->capacity;
>
> if (local_group) {
> - this_load = avg_load;
> + this_runnable_load = runnable_load;
> + this_avg_load = avg_load;
> this_spare = max_spare_cap;
> } else {
> - if (avg_load < min_load) {
> - min_load = avg_load;
> + if (min_runnable_load > (runnable_load + imbalance)) {
> + /*
> + * The runnable load is significantly smaller
> + * so we can pick this new cpu
> + */
> + min_runnable_load = runnable_load;
> + min_avg_load = avg_load;
> + idlest = group;
> + } else if ((runnable_load < (min_runnable_load + imbalance)) &&
> + (100*min_avg_load > imbalance_scale*avg_load)) {
> + /*
> + * The runnable loads are close so we take
> + * into account blocked load through avg_load
> + * which is blocked + runnable load
> + */
> + min_avg_load = avg_load;
> idlest = group;
> }
>
> @@ -5470,13 +5495,16 @@ find_idlest_group(struct sched_domain *sd, struct task_struct *p,
> goto no_spare;
>
> if (this_spare > task_util(p) / 2 &&
> - imbalance*this_spare > 100*most_spare)
> + imbalance_scale*this_spare > 100*most_spare)
> return NULL;
> else if (most_spare > task_util(p) / 2)
> return most_spare_sg;
>
> no_spare:
> - if (!idlest || 100*this_load < imbalance*min_load)
> + if (!idlest ||
> + (min_runnable_load > (this_runnable_load + imbalance)) ||
> + ((this_runnable_load < (min_runnable_load + imbalance)) &&
> + (100*min_avg_load > imbalance_scale*this_avg_load)))
I don't get why you have imbalance_scale applied to this_avg_load and
not min_avg_load. IIUC, you end up preferring non-local groups?
If we take the example where this_runnable_load == min_runnable_load and
this_avg_load == min_avg_load. In this case, and in cases where
min_avg_load is slightly bigger than this_avg_load, we end up picking
the 'idlest' group even if the local group is equally good or even
slightly better?
> return NULL;
> return idlest;
> }
Overall, I like that load_avg is being brought in to make better
decisions. The variable naming is a bit confusing. For example,
runnable_load is a capacity-average just like avg_load. 'imbalance' is
now an absolute capacity-average margin, but it is hard to come up with
better short alternatives.
Although 'imbalance' is based on the existing imbalance_pct, I find
somewhat arbitrary. Why is (imbalance_pct-100)*1024/100 a good absolute
margin to define the interval where we want to consider load_avg? I
guess it is case of 'we had to pick some value', which we have done in
many other places. Though, IMHO, it is a bit strange that imbalance_pct
is used in two different ways to bias comparison in the same function.
It used to be only used as a scaling factor (now imbalance_scale), while
this patch proposes to use it for computing an absolute margin
(imbalance) as well. It is not major issue, but it is not clear why it
is used differently to compare two metrics that are relatively closely
related.
Morten
^ permalink raw reply
* Re: [RFC] pinctrl: imx: use radix trees for groups and functions
From: Linus Walleij @ 2016-11-30 12:48 UTC (permalink / raw)
To: Gary Bisson
Cc: Shawn Guo, Peng Fan, linux-gpio@vger.kernel.org,
linux-kernel@vger.kernel.org, Pantelis Antoniou,
Vladimir Zapolskiy
In-Reply-To: <20161124233824.17424-1-gary.bisson@boundarydevices.com>
On Fri, Nov 25, 2016 at 12:38 AM, Gary Bisson
<gary.bisson@boundarydevices.com> wrote:
> This change is inspired from the pinctrl-single architecture.
>
> The problem with current implementation is that it isn't possible
> to add/remove functions and/or groups dynamically. The radix tree
> offers an easy way to do so. The intent is to offer a follow-up
> patch later that will enable the use of pinctrl nodes in dt-overlays.
>
> Signed-off-by: Gary Bisson <gary.bisson@boundarydevices.com>
I would like to see some feedback from one of the driver maintainers?
Else just resend it without RFC I guess.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 2/2] Synopsys USB 2.0 Device Controller (UDC) Driver
From: Felipe Balbi @ 2016-11-30 12:46 UTC (permalink / raw)
To: Raviteja Garimella
Cc: Rob Herring, Mark Rutland, Greg Kroah-Hartman, devicetree,
linux-kernel, BCM Kernel Feedback, linux-usb, John Youn
In-Reply-To: <CAEHZuqNgDwJL7HCP18R_M8TZcW-mENQsfyChv0_Zmm4M2ZTOkg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 872 bytes --]
Hi,
Raviteja Garimella <raviteja.garimella@broadcom.com> writes:
> Hi Balbi,
>
> On Wed, Nov 30, 2016 at 4:10 PM, Felipe Balbi <balbi@kernel.org> wrote:
>>
>> Hi,
>>
>> Raviteja Garimella <raviteja.garimella@broadcom.com> writes:
>>> This is driver for Synopsys Designware Cores USB Device
>>> Controller (UDC) Subsystem with the AMBA Advanced High-Performance
>>> Bus (AHB). This driver works with Synopsys UDC20 products.
>>>
>>> Signed-off-by: Raviteja Garimella <raviteja.garimella@broadcom.com>
>>
>> use drivers/usb/dwc2 instead of duplicating it.
>
> The ones we have in drivers/usb/dwc2 is for Designware high speed OTG
> controller IP. The one that I submitted for review is for USB Device
> controller IP (UDC). The IPs are different.
I'll wait for John's confirmation that this really isn't compatible with
dwc2. John?
--
balbi
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] Synopsys USB 2.0 Device Controller (UDC) Driver
From: Raviteja Garimella @ 2016-11-30 12:42 UTC (permalink / raw)
To: Felipe Balbi
Cc: Rob Herring, Mark Rutland, Greg Kroah-Hartman, devicetree,
linux-kernel, BCM Kernel Feedback, linux-usb, John Youn
In-Reply-To: <874m2pntdh.fsf@linux.intel.com>
Hi Balbi,
On Wed, Nov 30, 2016 at 4:10 PM, Felipe Balbi <balbi@kernel.org> wrote:
>
> Hi,
>
> Raviteja Garimella <raviteja.garimella@broadcom.com> writes:
>> This is driver for Synopsys Designware Cores USB Device
>> Controller (UDC) Subsystem with the AMBA Advanced High-Performance
>> Bus (AHB). This driver works with Synopsys UDC20 products.
>>
>> Signed-off-by: Raviteja Garimella <raviteja.garimella@broadcom.com>
>
> use drivers/usb/dwc2 instead of duplicating it.
The ones we have in drivers/usb/dwc2 is for Designware high speed OTG
controller IP. The one that I submitted for review is for USB Device
controller IP (UDC). The IPs are different.
Thanks,
Ravi
>
> --
> balbi
^ permalink raw reply
* Re: [PATCH] watchdog: meson: Remove unneeded platform MODULE_ALIAS
From: Javier Martinez Canillas @ 2016-11-30 12:41 UTC (permalink / raw)
To: Guenter Roeck, Wim Van Sebroeck
Cc: linux-kernel, linux-watchdog, Kevin Hilman, Carlo Caione,
linux-amlogic, linux-arm-kernel
In-Reply-To: <66487a0e-1d20-519f-6cbf-645f8bfd33da@roeck-us.net>
Hello Guenter,
On 11/30/2016 07:59 AM, Guenter Roeck wrote:
> On 11/29/2016 06:57 AM, Javier Martinez Canillas wrote:
>> Hello Wim,
>>
>> On 10/20/2016 07:28 PM, Guenter Roeck wrote:
>>> On Wed, Oct 19, 2016 at 04:49:42PM -0300, Javier Martinez Canillas wrote:
>>>> The Amlogic Meson is a DT-only platform, which means the devices are
>>>> registered via OF and not using the legacy platform devices support.
>>>>
>>>> So there's no need to have a MODULE_ALIAS("platform:meson-gxbb-wdt")
>>>> since the reported uevent MODALIAS to user-space will be the OF one.
>>>>
>>>> Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
>>>
>>> Reviewed-by: Guenter Roeck <linux@roeck-us.net>
>>>
>>
>> Any comments about this patch? There are other two similar fixes for
>> watchdog drivers that were also reviewed by Guenter but never picked:
>>
>> https://lkml.org/lkml/2016/10/14/412
>> https://lkml.org/lkml/2016/10/14/413
>>
>> Best regards,
>>
> The patches are all in my watchdog-next branch, so Wim will hopefully
> pick them up for the next release.
>
Great, thanks a lot for the info.
> Guenter
>
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
^ permalink raw reply
* Re: [PATCH v2 0/9] openrisc: Misc fixes from backlog
From: Stafford Horne @ 2016-11-30 12:40 UTC (permalink / raw)
To: Guenter Roeck
Cc: Stafford Horne, stefan.kristiansson, jonas, blue, robh,
linux-kernel, openrisc
In-Reply-To: <20161130012311.GA4833@roeck-us.net>
On Tue, 29 Nov 2016, Guenter Roeck wrote:
> On Mon, Nov 14, 2016 at 10:30:30PM +0900, Stafford Horne wrote:
>> Hello,
>>
>> This patch is a small set of fixes from the openrisc backlog. These
>> changes fix several issues with the openrisc build on modern tool chains
>> and address other issues which have cropped up as the kernel has been
>> getting updated.
>>
>
> Do you plan to send those patches to Linus yourself, or do you want me to do it
> for you this time ? If so I'd ask for the patch series to be added to -next
> and send it to Linus after the commit window opens. Let me know.
Hi Guenter,
Thanks for following up. One of the members of the openrisc team was able
to get his key signed recently [0]. But, it puts me at 4 levels from
Linus, which may not be good enough for accepting pull requests. At the
same time, I am working with one Japan kernel developer to get my key
signed, but there was a minor issue when we met. I hope that can get
resolved this friday when I meet again at Japan Technical Jamboree [1].
You might not be interested in all of that. I will do the following:
1 Create for-next branch on the github openrisc/linux with my current
patch set
2 Send a mail to Stephen Rothwell for including in linux next
3 When the merge window opens either the other OpenRISC maintainer or I
will create a signed tag and send a pull reuest to linus.
If those done work we will ask you for help.
Thanks for your help,
-Stafford
[0]
https://pgp.cs.uu.nl/mk_path.cgi?FROM=00411886&TO=5E6627E4&PATHS=trust+paths
[1] http://elinux.org/Japan_Technical_Jamboree_59
>> Consider for Pull:
>>
>> The following changes since commit a25f0944ba9b1d8a6813fd6f1a86f1bd59ac25a6:
>>
>> Linux 4.9-rc5 (2016-11-13 10:32:32 -0800)
>>
>> are available in the git repository at:
>>
>> https://github.com/stffrdhrn/linux.git tags/or1k-fixes-4.9
>>
>> for you to fetch changes up to a9fae5563e34217ff99efafde7e7bf607a5d5ec6:
>>
>> openrisc: include l.swa in check for write data pagefault (2016-11-14 21:58:33 +0900)
>>
>> Regards,
>> Stafford
>>
>> Changes since V1:
>> - Removed SMP option patch and replaced with NR_CPUS default value
>> - Removed Apply transparent_union on semun patch as its handled by libc
>> - Added memblock patch as suggested by Jonas
>> - Added MAINTAINERS patch as suggested by Guenter
>> - Added l.swa patch as its needed to fix musl programs
>> - Improved commit message on rt_sigreturn patch
>>
>> Christian Svensson (1):
>> openrisc: Add thread-local storage (TLS) support
>>
>> Guenter Roeck (1):
>> openrisc: Support both old (or32) and new (or1k) toolchain
>>
>> Jonas Bonn (1):
>> openrisc: restore all regs on rt_sigreturn
>>
>> Rob Herring (1):
>> openrisc: remove the redundant of_platform_populate
>>
>> Stafford Horne (3):
>> openrisc: add NR_CPUS Kconfig default value
>> openrisc: Consolidate setup to use memblock instead of bootmem
>> openrisc: Updates after openrisc.net has been lost
>>
>> Stefan Kristiansson (2):
>> openrisc: fix PTRS_PER_PGD define
>> openrisc: include l.swa in check for write data pagefault
>>
>> MAINTAINERS | 6 +++--
>> arch/openrisc/Kconfig | 4 ++++
>> arch/openrisc/README.openrisc | 8 +++----
>> arch/openrisc/TODO.openrisc | 3 ---
>> arch/openrisc/include/asm/pgalloc.h | 1 -
>> arch/openrisc/include/asm/pgtable.h | 2 +-
>> arch/openrisc/kernel/entry.S | 12 ++++++++--
>> arch/openrisc/kernel/process.c | 13 ++++++++++
>> arch/openrisc/kernel/setup.c | 48 ++++++++++---------------------------
>> arch/openrisc/kernel/vmlinux.lds.S | 8 ++++++-
>> arch/openrisc/mm/init.c | 4 ++--
>> arch/openrisc/mm/ioremap.c | 4 ----
>> 12 files changed, 58 insertions(+), 55 deletions(-)
>>
>> --
>> 2.7.4
>>
>
^ permalink raw reply
* Re: [PATCH] mm: page_alloc: High-order per-cpu page allocator v3
From: Jesper Dangaard Brouer @ 2016-11-30 12:40 UTC (permalink / raw)
To: Mel Gorman
Cc: brouer, Andrew Morton, Christoph Lameter, Michal Hocko,
Vlastimil Babka, Johannes Weiner, Linux-MM, Linux-Kernel,
Rick Jones, Paolo Abeni
In-Reply-To: <20161127131954.10026-1-mgorman@techsingularity.net>
On Sun, 27 Nov 2016 13:19:54 +0000 Mel Gorman <mgorman@techsingularity.net> wrote:
[...]
> SLUB has been the default small kernel object allocator for quite some time
> but it is not universally used due to performance concerns and a reliance
> on high-order pages. The high-order concerns has two major components --
> high-order pages are not always available and high-order page allocations
> potentially contend on the zone->lock. This patch addresses some concerns
> about the zone lock contention by extending the per-cpu page allocator to
> cache high-order pages. The patch makes the following modifications
>
> o New per-cpu lists are added to cache the high-order pages. This increases
> the cache footprint of the per-cpu allocator and overall usage but for
> some workloads, this will be offset by reduced contention on zone->lock.
This will also help performance of NIC driver that allocator
higher-order pages for their RX-ring queue (and chop it up for MTU).
I do like this patch, even-though I'm working on moving drivers away
from allocation these high-order pages.
Acked-by: Jesper Dangaard Brouer <brouer@redhat.com>
[...]
> This is the result from netperf running UDP_STREAM on localhost. It was
> selected on the basis that it is slab-intensive and has been the subject
> of previous SLAB vs SLUB comparisons with the caveat that this is not
> testing between two physical hosts.
I do like you are using a networking test to benchmark this. Looking at
the results, my initial response is that the improvements are basically
too good to be true.
Can you share how you tested this with netperf and the specific netperf
parameters?
e.g.
How do you configure the send/recv sizes?
Have you pinned netperf and netserver on different CPUs?
For localhost testing, when netperf and netserver run on the same CPU,
you observer half the performance, very intuitively. When pinning
netperf and netserver (via e.g. option -T 1,2) you observe the most
stable results. When allowing netperf and netserver to migrate between
CPUs (default setting), the real fun starts and unstable results,
because now the CPU scheduler is also being tested, and my experience
is also more "fun" memory situations occurs, as I guess we are hopping
between more per CPU alloc caches (also affecting the SLUB per CPU usage
pattern).
> 2-socket modern machine
> 4.9.0-rc5 4.9.0-rc5
> vanilla hopcpu-v3
The kernel from 4.9.0-rc5-vanilla to 4.9.0-rc5-hopcpu-v3 only contains
this single change right?
Netdev/Paolo recently (in net-next) optimized the UDP code path
significantly, and I just want to make sure your results are not
affected by these changes.
> Hmean send-64 178.38 ( 0.00%) 256.74 ( 43.93%)
> Hmean send-128 351.49 ( 0.00%) 507.52 ( 44.39%)
> Hmean send-256 671.23 ( 0.00%) 1004.19 ( 49.60%)
> Hmean send-1024 2663.60 ( 0.00%) 3910.42 ( 46.81%)
> Hmean send-2048 5126.53 ( 0.00%) 7562.13 ( 47.51%)
> Hmean send-3312 7949.99 ( 0.00%) 11565.98 ( 45.48%)
> Hmean send-4096 9433.56 ( 0.00%) 12929.67 ( 37.06%)
> Hmean send-8192 15940.64 ( 0.00%) 21587.63 ( 35.43%)
> Hmean send-16384 26699.54 ( 0.00%) 32013.79 ( 19.90%)
> Hmean recv-64 178.38 ( 0.00%) 256.72 ( 43.92%)
> Hmean recv-128 351.49 ( 0.00%) 507.47 ( 44.38%)
> Hmean recv-256 671.20 ( 0.00%) 1003.95 ( 49.57%)
> Hmean recv-1024 2663.45 ( 0.00%) 3909.70 ( 46.79%)
> Hmean recv-2048 5126.26 ( 0.00%) 7560.67 ( 47.49%)
> Hmean recv-3312 7949.50 ( 0.00%) 11564.63 ( 45.48%)
> Hmean recv-4096 9433.04 ( 0.00%) 12927.48 ( 37.04%)
> Hmean recv-8192 15939.64 ( 0.00%) 21584.59 ( 35.41%)
> Hmean recv-16384 26698.44 ( 0.00%) 32009.77 ( 19.89%)
>
> 1-socket 6 year old machine
> 4.9.0-rc5 4.9.0-rc5
> vanilla hopcpu-v3
> Hmean send-64 87.47 ( 0.00%) 127.14 ( 45.36%)
> Hmean send-128 174.36 ( 0.00%) 256.42 ( 47.06%)
> Hmean send-256 347.52 ( 0.00%) 509.41 ( 46.59%)
> Hmean send-1024 1363.03 ( 0.00%) 1991.54 ( 46.11%)
> Hmean send-2048 2632.68 ( 0.00%) 3759.51 ( 42.80%)
> Hmean send-3312 4123.19 ( 0.00%) 5873.28 ( 42.45%)
> Hmean send-4096 5056.48 ( 0.00%) 7072.81 ( 39.88%)
> Hmean send-8192 8784.22 ( 0.00%) 12143.92 ( 38.25%)
> Hmean send-16384 15081.60 ( 0.00%) 19812.71 ( 31.37%)
> Hmean recv-64 86.19 ( 0.00%) 126.59 ( 46.87%)
> Hmean recv-128 173.93 ( 0.00%) 255.21 ( 46.73%)
> Hmean recv-256 346.19 ( 0.00%) 506.72 ( 46.37%)
> Hmean recv-1024 1358.28 ( 0.00%) 1980.03 ( 45.77%)
> Hmean recv-2048 2623.45 ( 0.00%) 3729.35 ( 42.15%)
> Hmean recv-3312 4108.63 ( 0.00%) 5831.47 ( 41.93%)
> Hmean recv-4096 5037.25 ( 0.00%) 7021.59 ( 39.39%)
> Hmean recv-8192 8762.32 ( 0.00%) 12072.44 ( 37.78%)
> Hmean recv-16384 15042.36 ( 0.00%) 19690.14 ( 30.90%)
>
> This is somewhat dramatic but it's also not universal. For example, it was
> observed on an older HP machine using pcc-cpufreq that there was almost
> no difference but pcc-cpufreq is also a known performance hazard.
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* RE: Re: [PATCH] usb:hub: readibility and consistency in coding style
From: Atul Raj @ 2016-11-30 12:35 UTC (permalink / raw)
To: gregkh@linuxfoundation.org
Cc: Viresh Kumar, mathias.nyman@linux.intel.com,
stern@rowland.harvard.edu, baolu.lu@linux.intel.com,
oneukum@suse.com, hansy@nvidia.com, alcooperx@gmail.com,
atulraj.nith@gmail.com, dri-devel@lists.freedesktop.org,
linux-kernel@vger.kernel.org, Pankaj Singh
In-Reply-To: <20161130115139epcms5p3fb0520cf6cabcf69e470be63463a46d1@epcms5p3>
[-- Attachment #1: Type: text/plain, Size: 1737 bytes --]
Hi Greg,
I am so happy to get a mail from you and I am really sorry Greg that I disappointed you.
I will take utmost care in future.
I will send you correct patch in sometime.
for your ques
"Also, why are you including a ton of people who have nothing to do with
usb patches on this one?"
I got the name of people from get_maintainer.pl
from now I will include only you.
is it ok??
one more thing in another mail you replied to me as
On Wed, Nov 30, 2016 at 11:40:28AM +0000, Atul Raj wrote:
> changes in v2
> - added braces as suggested.
Why is this here?
>
> drivers/usb/core/hub.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
do you disagree with viresh comment of braces???
Thanks for your words.
Your Fan
Atul Raj
>
> On Wed, Nov 30, 2016 at 11:51:39AM +0000, Atul Raj wrote:
> > It is suggested to keep braces if there is a comment in if case as
> > comment also takes a line.
> > ---
> > drivers/usb/core/hub.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
>
> Ok, this is getting to be a joke.
>
> Take a few days off, relax, then try to send a patch that works to
> yourself first, and run it through scripts/checkpatch.pl to verify that
> it really is correct. Hint, this one isn't at all.
>
> Then, maybe you should start doing some work on drivers/staging/ first,
> which is where new developers should start out to work out all of these
> issues so you don't bother the other developers who are working on
> adding new features and fixing bugs.
>
> Also, why are you including a ton of people who have nothing to do with
> usb patches on this one?
>
> good luck,
>
> greg k-h
^ permalink raw reply
* Re: INFO: rcu_sched detected stalls on CPUs/tasks with `kswapd` and `mem_cgroup_shrink_node`
From: Paul Menzel @ 2016-11-30 12:31 UTC (permalink / raw)
To: Paul E. McKenney, Michal Hocko
Cc: Donald Buczek, dvteam, linux-mm, linux-kernel, Josh Triplett
In-Reply-To: <20161130115442.GA19271@linux.vnet.ibm.com>
On 11/30/16 12:54, Paul E. McKenney wrote:
> On Wed, Nov 30, 2016 at 03:53:20AM -0800, Paul E. McKenney wrote:
>> On Wed, Nov 30, 2016 at 12:09:44PM +0100, Michal Hocko wrote:
>>> [CCing Paul]
>>>
>>> On Wed 30-11-16 11:28:34, Donald Buczek wrote:
>>> [...]
>>>> shrink_active_list gets and releases the spinlock and calls cond_resched().
>>>> This should give other tasks a chance to run. Just as an experiment, I'm
>>>> trying
>>>>
>>>> --- a/mm/vmscan.c
>>>> +++ b/mm/vmscan.c
>>>> @@ -1921,7 +1921,7 @@ static void shrink_active_list(unsigned long
>>>> nr_to_scan,
>>>> spin_unlock_irq(&pgdat->lru_lock);
>>>>
>>>> while (!list_empty(&l_hold)) {
>>>> - cond_resched();
>>>> + cond_resched_rcu_qs();
>>>> page = lru_to_page(&l_hold);
>>>> list_del(&page->lru);
>>>>
>>>> and didn't hit a rcu_sched warning for >21 hours uptime now. We'll see.
>>>
>>> This is really interesting! Is it possible that the RCU stall detector
>>> is somehow confused?
>>
>> No, it is not confused. Again, cond_resched() is not a quiescent
>> state unless it does a context switch. Therefore, if the task running
>> in that loop was the only runnable task on its CPU, cond_resched()
>> would -never- provide RCU with a quiescent state.
>>
>> In contrast, cond_resched_rcu_qs() unconditionally provides RCU
>> with a quiescent state (hence the _rcu_qs in its name), regardless
>> of whether or not a context switch happens.
>>
>> It is therefore expected behavior that this change might prevent
>> RCU CPU stall warnings.
>
> I should add... This assumes that CONFIG_PREEMPT=n. So what is
> CONFIG_PREEMPT?
It’s not selected.
```
# CONFIG_PREEMPT is not set
```
>>>> Is preemption disabled for another reason?
>>>
>>> I do not think so. I will have to double check the code but this is a
>>> standard sleepable context. Just wondering what is the PREEMPT
>>> configuration here?
Kind regards,
Paul
^ permalink raw reply
* Re: [patch V2 00/12] thermal/x86_pkg_temp: Sanitize hotplug and locking
From: Zhang Rui @ 2016-11-30 12:30 UTC (permalink / raw)
To: Pandruvada, Srinivas, tglx@linutronix.de,
linux-kernel@vger.kernel.org
Cc: edubezval@gmail.com, peterz@infradead.org, rt@linutronix.de,
linux-pm@vger.kernel.org, bp@alien8.de, x86@kernel.org
In-Reply-To: <1479844260.6544.220.camel@intel.com>
On Tue, 2016-11-22 at 12:51 -0700, Pandruvada, Srinivas wrote:
> On Tue, 2016-11-22 at 17:57 +0000, Thomas Gleixner wrote:
> >
> > Changes vs. V1: Fix the package removal wreckage reported by
> > Srinivas
> >
> I haven't looked at individual patch but tested the series as a
> whole.
>
> So Rui, you can add
>
> Tested-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
>
applied.
thanks,
rui
^ permalink raw reply
* Re: [PATCH 4/4] locking: Add kselftests for ww_mutex stress
From: Maarten Lankhorst @ 2016-11-30 12:29 UTC (permalink / raw)
To: Chris Wilson, linux-kernel; +Cc: Peter Zijlstra, Nicolai Hähnle
In-Reply-To: <20161130003548.22266-4-chris@chris-wilson.co.uk>
Op 30-11-16 om 01:35 schreef Chris Wilson:
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: Maarten Lankhorst <dev@mblankhorst.nl>
> Cc: Nicolai Hähnle <nhaehnle@gmail.com>
> ---
> kernel/locking/test-ww_mutex.c | 134 +++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 134 insertions(+)
>
> diff --git a/kernel/locking/test-ww_mutex.c b/kernel/locking/test-ww_mutex.c
> index 63a5031de138..c367014f62dc 100644
> --- a/kernel/locking/test-ww_mutex.c
> +++ b/kernel/locking/test-ww_mutex.c
> @@ -21,6 +21,9 @@
> #include <linux/kthread.h>
> #include <linux/ww_mutex.h>
> #include <linux/completion.h>
> +#include <linux/random.h>
> +#include <linux/slab.h>
> +#include <linux/delay.h>
>
> MODULE_LICENSE("GPL");
> MODULE_AUTHOR("Intel Corporation");
> @@ -224,6 +227,129 @@ static int test_abba(void)
> return ret;
> }
>
> +struct stress {
> + struct work_struct work;
> + struct ww_mutex *locks;
> + int nlocks;
> +};
> +
> +static int *get_random_order(int count)
> +{
> + int *order;
> + int n, r, tmp;
> +
> + order = kmalloc_array(count, sizeof(*order), GFP_TEMPORARY);
> + if (!order)
> + return order;
> +
> + for (n = 0; n < count; n++)
> + order[n] = n;
> +
> + for (n = count - 1; n > 1; n--) {
> + r = get_random_int() % (n + 1);
> + if (r != n) {
> + tmp = order[n];
> + order[n] = order[r];
> + order[r] = tmp;
> + }
> + }
> +
> + return order;
> +}
> +
> +static void stress_work(struct work_struct *work)
> +{
> + struct stress *stress = container_of(work, typeof(*stress), work);
> + const int nlocks = stress->nlocks;
> + struct ww_mutex *locks = stress->locks;
> + struct ww_acquire_ctx ctx;
> + int contended = -1;
> + int *order;
> + int n, ret;
> +
> + order = get_random_order(nlocks);
> + if (!order)
> + return;
> +
> + ww_acquire_init(&ctx, &ww_class);
> +
> +retry:
> + ret = 0;
> + for (n = 0; n < nlocks; n++) {
> + if (n == contended)
> + continue;
> +
> + ret = ww_mutex_lock(&locks[order[n]], &ctx);
> + if (ret < 0)
> + break;
> + }
What's wrong with attempting to lock the contended lock here?
Who knows, this might find some more bugs than the functional tests already do.
> + if (!ret)
> + usleep_range(1000, 2000); /* dummy load */
> +
> + if (contended > n)
> + ww_mutex_unlock(&locks[order[contended]]);
> + contended = n;
> + while (n--)
> + ww_mutex_unlock(&locks[order[n]]);
> +
> + if (ret == -EDEADLK) {
> + ww_mutex_lock_slow(&locks[order[contended]], &ctx);
> + goto retry;
> + }
> +
> + if (ret)
> + pr_err_once("ww_mutex stress test failed with %d\n", ret);
> +
> + ww_acquire_fini(&ctx);
> +
> + kfree(order);
> + kfree(stress);
> +}
> +
> +static int stress(int nlocks, int count)
> +{
> + struct ww_mutex *locks;
> + struct workqueue_struct *wq;
> + int ret = -ENOMEM;
> + int n;
> +
> + wq = alloc_workqueue("test-ww_mutex", WQ_UNBOUND, 0);
> + if (!wq)
> + return -ENOMEM;
> +
> + locks = kmalloc_array(nlocks, sizeof(*locks), GFP_KERNEL);
> + if (!locks)
> + goto err;
> +
> + for (n = 0; n < nlocks; n++)
> + ww_mutex_init(&locks[n], &ww_class);
> +
> + for (n = 0; n < count; n++) {
> + struct stress *stress;
> +
> + stress = kmalloc(sizeof(*stress), GFP_KERNEL);
> + if (!stress)
> + break;
> +
> + INIT_WORK(&stress->work, stress_work);
> + stress->locks = locks;
> + stress->nlocks = nlocks;
> +
> + queue_work(wq, &stress->work);
> + }
> +
> + flush_workqueue(wq);
> +
> + for (n = 0; n < nlocks; n++)
> + ww_mutex_destroy(&locks[n]);
> + kfree(locks);
> +
> + ret = 0;
> +err:
> + destroy_workqueue(wq);
> + return ret;
> +}
> +
> static int __init test_ww_mutex_init(void)
> {
> int ret;
> @@ -240,6 +366,14 @@ static int __init test_ww_mutex_init(void)
> if (ret)
> return ret;
>
> + ret = stress(16, 1024);
> + if (ret)
> + return ret;
> +
> + ret = stress(4096, 1024);
> + if (ret)
> + return ret;
> +
> return 0;
> }
>
^ permalink raw reply
* Re: [lkp] [mm] e7c1db75fe: BUG:sleeping_function_called_from_invalid_context_at_mm/page_alloc.c
From: Sudeep Holla @ 2016-11-30 12:28 UTC (permalink / raw)
To: paulmck, Michal Hocko
Cc: Sudeep Holla, Boris Zhmurov, Andrew Morton, Johannes Weiner,
Vlastimil Babka, LKML, lkp, kernel test robot
In-Reply-To: <20161130074014.GN3924@linux.vnet.ibm.com>
On 30/11/16 07:40, Paul E. McKenney wrote:
> On Wed, Nov 30, 2016 at 08:16:02AM +0100, Michal Hocko wrote:
>> On Tue 29-11-16 11:14:48, Paul E. McKenney wrote:
>>> On Tue, Nov 29, 2016 at 05:21:19PM +0000, Sudeep Holla wrote:
>>>> On Sun, Nov 27, 2016 at 6:16 PM, kernel test robot
>>>> <xiaolong.ye@intel.com> wrote:
>>>>>
>>>>> FYI, we noticed the following commit:
>>>>>
>>>>> commit e7c1db75fed821a961ce1ca2b602b08e75de0cd8 ("mm: Prevent __alloc_pages_nodemask() RCU CPU stall warnings")
>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git rcu/next
>>>>>
>>>>> in testcase: boot
>>>>>
>>>>> on test machine: qemu-system-x86_64 -enable-kvm -cpu Nehalem -smp 2 -m 1G
>>>>>
>>>>> caused below changes:
>>>>>
>>>> [...]
>>>>
>>>>> [ 8.953192] BUG: sleeping function called from invalid context at mm/page_alloc.c:3746
>>>>> [ 8.956353] in_atomic(): 1, irqs_disabled(): 1, pid: 0, name: swapper/0
>>>>
>>>> I am observing similar BUG/backtrace even on ARM64 platform.
>>>
>>> Does the (untested) patch below help?
Yes it didn't work for me either. Adding the log from my setup(in case
it's useful)
Regards,
Sudeep
--->8
BUG: sleeping function called from invalid context at mm/page_alloc.c:3775
in_atomic(): 1, irqs_disabled(): 128, pid: 1, name: swapper/0
1 lock held by swapper/0/1:
#0: (&sig->cred_guard_mutex ){+.+.+.}, at: prepare_bprm_creds+0x2c/0x70
irq event stamp: 508063
hardirqs last enabled at (508062): __netdev_alloc_skb+0x11c/0x160
hardirqs last disabled at (508063): __slab_alloc.isra.22.constprop.26+0x30/0x90
softirqs last enabled at (508052): xprt_end_transmit+0x4c/0x60
softirqs last disabled at (508053): do_softirq.part.4+0x7c/0x98
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.9.0-rc7-next-20161130-00010-ga0f9af725c5d #218
Hardware name: ARM LTD ARM Juno Development Platform/ARM Juno Development Platform, BIOS EDK II Nov 29 2016
Call trace:
dump_backtrace+0x0/0x260
show_stack+0x24/0x30
dump_stack+0xac/0xe8
___might_sleep+0x14c/0x1f8
__alloc_pages_nodemask+0x414/0xef0
new_slab+0xa4/0x558
___slab_alloc.constprop.27+0x2f8/0x378
__slab_alloc.isra.22.constprop.26+0x4c/0x90
kmem_cache_alloc+0x388/0x430
__build_skb+0x34/0xc0
__netdev_alloc_skb+0xf0/0x160
smsc911x_poll+0x9c/0x280
net_rx_action+0x200/0x510
__do_softirq+0x12c/0x6fc
do_softirq.part.4+0x7c/0x98
__local_bh_enable_ip+0x110/0x138
_raw_spin_unlock_bh+0x40/0x50
xprt_end_transmit+0x4c/0x60
call_transmit_status+0x58/0x100
call_transmit+0x178/0x1e8
__rpc_execute+0xa0/0x680
rpc_execute+0xb4/0x298
rpc_run_task+0x11c/0x168
nfs4_call_sync_sequence+0x6c/0x98
_nfs4_proc_access+0xe8/0x170
nfs4_proc_access+0x88/0x2a0
nfs_do_access+0x458/0x778
nfs_permission+0x2c8/0x2f8
__inode_permission+0xa0/0x100
inode_permission+0x2c/0x70
link_path_walk+0x98/0x518
path_openat+0x74/0x340
do_filp_open+0x70/0xf8
do_open_execat+0x70/0x1a0
do_execveat_common.isra.14+0x288/0x998
do_execve+0x44/0x58
run_init_process+0x38/0x48
try_to_run_init_process+0x20/0x58
kernel_init+0xb4/0x108
ret_from_fork+0x10/0x30
BUG: sleeping function called from invalid context at mm/page_alloc.c:3775
in_atomic(): 1, irqs_disabled(): 128, pid: 98, name: kworker/0:1
3 locks held by kworker/0:1/98:
#0: ("rpciod" ){.+.+..} , at: process_one_work+0x198/0x818
#1: ((&task->u.tk_work)){+.+...}, at: process_one_work+0x198/0x818
#2: (&(&clnt->cl_lock)->rlock){+.+...}, at: rpc_task_release_client+0x38/0xb0
irq event stamp: 31359
hardirqs last enabled at (31358): _raw_spin_unlock_irqrestore+0x84/0x90
hardirqs last disabled at (31359): __netdev_alloc_skb+0xa8/0x160
softirqs last enabled at (31252): rpc_wake_up_first_on_wq+0x84/0x200
softirqs last disabled at (31255): irq_exit+0xe8/0x148
CPU: 0 PID: 98 Comm: kworker/0:1 Tainted: G W 4.9.0-rc7-next-20161130-00010-ga0f9af725c5d #218
Hardware name: ARM LTD ARM Juno Development Platform/ARM Juno Development Platform, BIOS EDK II Nov 29 2016
Workqueue: rpciod rpc_async_schedule
Call trace:
dump_backtrace+0x0/0x260
show_stack+0x24/0x30
dump_stack+0xac/0xe8
___might_sleep+0x14c/0x1f8
__alloc_pages_nodemask+0x414/0xef0
__alloc_page_frag+0xa8/0x158
__netdev_alloc_skb+0xcc/0x160
smsc911x_poll+0x9c/0x280
net_rx_action+0x200/0x510
__do_softirq+0x12c/0x6fc
irq_exit+0xe8/0x148
__handle_domain_irq+0x6c/0xc0
gic_handle_irq+0x5c/0xb0
BUG: sleeping function called from invalid context at mm/page_alloc.c:3775
in_atomic(): 1, irqs_disabled(): 128, pid: 1326, name: kworker/0:1H
4 locks held by kworker/0:1H/1326:
#0: ("xprtiod"){.+.+.+}, at: process_one_work+0x198/0x818
#1: ((&transport->recv_worker)){+.+...}, at: process_one_work+0x198/0x818
#2: (&new->recv_mutex){+.+...}, at: xs_tcp_data_receive_workfn+0x4c/0x2f8
#3: (sk_lock-AF_INET-RPC){+.+...}, at: xs_tcp_data_receive_workfn+0x74/0x2f8
irq event stamp: 41851
hardirqs last enabled at (41850): _raw_spin_unlock_irqrestore+0x84/0x90
hardirqs last disabled at (41851): __netdev_alloc_skb+0xa8/0x160
softirqs last enabled at (41836): xs_tcp_data_recv+0x580/0x960
softirqs last disabled at (41843): irq_exit+0xe8/0x148
CPU: 0 PID: 1326 Comm: kworker/0:1H Tainted: G W 4.9.0-rc7-next-20161130-00010-ga0f9af725c5d #218
Hardware name: ARM LTD ARM Juno Development Platform/ARM Juno Development Platform, BIOS EDK II Nov 29 2016
Workqueue: xprtiod xs_tcp_data_receive_workfn
Call trace:
dump_backtrace+0x0/0x260
show_stack+0x24/0x30
dump_stack+0xac/0xe8
___might_sleep+0x14c/0x1f8
__alloc_pages_nodemask+0x414/0xef0
__alloc_page_frag+0xa8/0x158
__netdev_alloc_skb+0xcc/0x160
smsc911x_poll+0x9c/0x280
net_rx_action+0x200/0x510
__do_softirq+0x12c/0x6fc
irq_exit+0xe8/0x148
__handle_domain_irq+0x6c/0xc0
gic_handle_irq+0x5c/0xb0
Exception stack(0xffff800974d4b9e0 to 0xffff800974d4bb10)
b9e0: ffff800974c59600 000000000001fc5a 0000800976db6000 fffffffffffffe50
ba00: 0000000000000004 0000000000000040 0000800976db6000 ffff000009353c38
ba20: 0000000000000001 00010643c0000000 c000000000100400 0010080000012144
ba40: 00012145c0000000 c000000000101000 0010180000010646 0000000000000000
ba60: 0000000000000000 0000000000000000 0000000000000000 ffff7e0025d34600
ba80: 00000000009f4d18 0000000000000040 0000000000000003 0000000000000000
baa0: ffff7e0025d34800 0000000000000001 000000000018bce1 ffff800974c0c830
bac0: 0000000000000000 ffff800974d4bb10 ffff00000821b9bc ffff800974d4bb10
bae0: ffff00000821b9c0 0000000060000045 0000000000000040 0000000000000000
bb00: ffffffffffffffff ffff00000821b9bc
el1_irq+0xb8/0x130
__free_pages_ok+0x1d0/0x4b0
__free_page_frag+0x78/0x88
skb_free_head+0x3c/0x48
skb_release_data+0xd0/0xf8
skb_release_all+0x30/0x40
__kfree_skb+0x20/0x38
tcp_read_sock+0x118/0x1d8
xs_tcp_data_receive_workfn+0x84/0x2f8
process_one_work+0x248/0x818
worker_thread+0x54/0x438
kthread+0xe0/0xf8
ret_from_fork+0x10/0x30
BUG: sleeping function called from invalid context at mm/page_alloc.c:3775
in_atomic(): 1, irqs_disabled(): 128, pid: 6, name: ksoftirqd/0
no locks held by ksoftirqd/0/6.
irq event stamp: 76667
hardirqs last enabled at (76666): _raw_spin_unlock_irqrestore+0x84/0x90
hardirqs last disabled at (76667): __netdev_alloc_skb+0xa8/0x160
softirqs last enabled at (76506): __do_softirq+0x5f4/0x6fc
softirqs last disabled at (76511): run_ksoftirqd+0x40/0xb0
CPU: 0 PID: 6 Comm: ksoftirqd/0 Tainted: G W 4.9.0-rc7-next-20161130-00010-ga0f9af725c5d #218
Hardware name: ARM LTD ARM Juno Development Platform/ARM Juno Development Platform, BIOS EDK II Nov 29 2016
Call trace:
dump_backtrace+0x0/0x260
show_stack+0x24/0x30
dump_stack+0xac/0xe8
___might_sleep+0x14c/0x1f8
__alloc_pages_nodemask+0x414/0xef0
__alloc_page_frag+0xa8/0x158
__netdev_alloc_skb+0xcc/0x160
smsc911x_poll+0x9c/0x280
net_rx_action+0x200/0x510
__do_softirq+0x12c/0x6fc
run_ksoftirqd+0x40/0xb0
smpboot_thread_fn+0x1d4/0x308
kthread+0xe0/0xf8
ret_from_fork+0x10/0x30
BUG: sleeping function called from invalid context at mm/page_alloc.c:3775
in_atomic(): 1, irqs_disabled(): 128, pid: 6, name: ksoftirqd/0
no locks held by ksoftirqd/0/6.
irq event stamp: 121831
hardirqs last enabled at (121830): _raw_spin_unlock_irqrestore+0x84/0x90
hardirqs last disabled at (121831): __netdev_alloc_skb+0xa8/0x160
softirqs last enabled at (121742): __do_softirq+0x5f4/0x6fc
softirqs last disabled at (121747): run_ksoftirqd+0x40/0xb0
CPU: 0 PID: 6 Comm: ksoftirqd/0 Tainted: G W 4.9.0-rc7-next-20161130-00010-ga0f9af725c5d #218
Hardware name: ARM LTD ARM Juno Development Platform/ARM Juno Development Platform, BIOS EDK II Nov 29 2016
Call trace:
dump_backtrace+0x0/0x260
show_stack+0x24/0x30
dump_stack+0xac/0xe8
___might_sleep+0x14c/0x1f8
__alloc_pages_nodemask+0x414/0xef0
__alloc_page_frag+0xa8/0x158
__netdev_alloc_skb+0xcc/0x160
smsc911x_poll+0x9c/0x280
net_rx_action+0x200/0x510
__do_softirq+0x12c/0x6fc
run_ksoftirqd+0x40/0xb0
smpboot_thread_fn+0x1d4/0x308
kthread+0xe0/0xf8
ret_from_fork+0x10/0x30
NET: Registered protocol family 10
===============================
suspicious RCU usage. ]
4.9.0-rc7-next-20161130-00010-ga0f9af725c5d #218 Tainted: G W
-------------------------------
kernel/sched/core.c:7747 Illegal context switch in RCU-bh read-side critical section!
other info that might help us debug this:
rcu_scheduler_active = 1, debug_locks = 1
3 locks held by systemd/1:
#0: (rtnl_mutex ){+.+.+.}, at: rtnl_lock+0x20/0x28
#1: (rcu_read_lock_bh){......}, at: ipv6_add_addr+0x70/0x548 [ipv6]
#2: (addrconf_hash_lock){+.....}, at: ipv6_add_addr+0x194/0x548 [ipv6]
stack backtrace:
CPU: 3 PID: 1 Comm: systemd Tainted: G W 4.9.0-rc7-next-20161130-00010-ga0f9af725c5d #218
Hardware name: ARM LTD ARM Juno Development Platform/ARM Juno Development Platform, BIOS EDK II Nov 29 2016
Call trace:
dump_backtrace+0x0/0x260
show_stack+0x24/0x30
dump_stack+0xac/0xe8
lockdep_rcu_suspicious+0xcc/0x110
___might_sleep+0x1e0/0x1f8
__alloc_pages_nodemask+0x414/0xef0
new_slab+0xa4/0x558
___slab_alloc.constprop.27+0x2f8/0x378
__slab_alloc.isra.22.constprop.26+0x4c/0x90
kmem_cache_alloc+0x388/0x430
dst_alloc+0x5c/0xb0
__ip6_dst_alloc+0x3c/0xa0 [ipv6]
ip6_dst_alloc+0x38/0x108 [ipv6]
addrconf_dst_alloc+0x4c/0x130 [ipv6]
ipv6_add_addr+0x274/0x548 [ipv6]
add_addr+0x4c/0xd8 [ipv6]
addrconf_notify+0x5c4/0xa98 [ipv6]
register_netdevice_notifier+0x1e0/0x1e8
addrconf_init+0xb8/0x270 [ipv6]
inet6_init+0x180/0x330 [ipv6]
do_one_initcall+0x44/0x138
do_init_module+0x64/0x1d0
load_module+0x1230/0x1560
SyS_finit_module+0x120/0x130
el0_svc_naked+0x24/0x28
BUG: sleeping function called from invalid context at mm/page_alloc.c:3775
in_atomic(): 1, irqs_disabled(): 128, pid: 1, name: systemd
3 locks held by systemd/1:
#0: (rtnl_mutex){+.+.+.} , at: rtnl_lock+0x20/0x28
#1: (rcu_read_lock_bh){......}, at: ipv6_add_addr+0x70/0x548 [ipv6]
#2: (addrconf_hash_lock){+.....}, at: ipv6_add_addr+0x194/0x548 [ipv6]
irq event stamp: 619543
hardirqs last enabled at (619541): __local_bh_enable_ip+0x88/0x138
hardirqs last disabled at (619543): __slab_alloc.isra.22.constprop.26+0x30/0x90
softirqs last enabled at (619540): ipv6_mc_up+0x4c/0x58 [ipv6]
softirqs last disabled at (619542): ipv6_add_addr+0x70/0x548 [ipv6]
CPU: 3 PID: 1 Comm: systemd Tainted: G W 4.9.0-rc7-next-20161130-00010-ga0f9af725c5d #218
Hardware name: ARM LTD ARM Juno Development Platform/ARM Juno Development Platform, BIOS EDK II Nov 29 2016
Call trace:
dump_backtrace+0x0/0x260
show_stack+0x24/0x30
dump_stack+0xac/0xe8
___might_sleep+0x14c/0x1f8
__alloc_pages_nodemask+0x414/0xef0
new_slab+0xa4/0x558
___slab_alloc.constprop.27+0x2f8/0x378
__slab_alloc.isra.22.constprop.26+0x4c/0x90
kmem_cache_alloc+0x388/0x430
dst_alloc+0x5c/0xb0
__ip6_dst_alloc+0x3c/0xa0 [ipv6]
ip6_dst_alloc+0x38/0x108 [ipv6]
addrconf_dst_alloc+0x4c/0x130 [ipv6]
ipv6_add_addr+0x274/0x548 [ipv6]
add_addr+0x4c/0xd8 [ipv6]
addrconf_notify+0x5c4/0xa98 [ipv6]
register_netdevice_notifier+0x1e0/0x1e8
addrconf_init+0xb8/0x270 [ipv6]
inet6_init+0x180/0x330 [ipv6]
do_one_initcall+0x44/0x138
do_init_module+0x64/0x1d0
load_module+0x1230/0x1560
SyS_finit_module+0x120/0x130
el0_svc_naked+0x24/0x28
^ permalink raw reply
* Re: [PATCH 00/11] locking/ww_mutex: Keep sorted wait list to avoid stampedes
From: Chris Wilson @ 2016-11-30 12:20 UTC (permalink / raw)
To: Nicolai Hähnle; +Cc: linux-kernel
In-Reply-To: <0e930160-2536-97d6-06a3-07cc0b1df651@gmail.com>
On Wed, Nov 30, 2016 at 12:52:28PM +0100, Nicolai Hähnle wrote:
> On 30.11.2016 10:40, Chris Wilson wrote:
> >On Mon, Nov 28, 2016 at 01:20:01PM +0100, Nicolai Hähnle wrote:
> >>I've included timings taken from a contention-heavy stress test to some of
> >>the patches. The stress test performs actual GPU operations which take a
> >>good chunk of the wall time, but even so, the series still manages to
> >>improve the wall time quite a bit.
> >
> >In looking at your contention scenarios, what was the average/max list
> >size? Just wondering if it makes sense to use an rbtree + first_waiter
> >instead of a sorted list from the start.
>
> I haven't measured this with the new series; previously, while I was
> debugging the deadlock on older kernels, I occasionally saw wait
> lists of up to ~20 tasks, spit-balling the average over all the
> deadlock cases I'd say the average was not more than ~5. The average
> _without_ deadlocks should be lower, if anything.
Right, I wasn't expecting the list to be large, certainly no larger than
cores typically. On the borderline of where a more complex tree starts
to pay off.
> I saw that your test cases go quite a bit higher, but even the
> rather extreme load I was testing with -- which is not quite a load
> from an actual application, though it is related to one -- has 40
> threads and so a theoretical maximum of 40.
The stress loads were just values plucked out of nowhere to try and have
a reasonable stab at hitting the deadlock. Certainly if we were to wrap
that up in a microbenchmark we would want to have wider coverage (so the
graph against contention is more useful).
Do you have a branch I can pull the patches for (or what did you use as
the base)?
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
^ permalink raw reply
* Re: [PATCH] IIO: Change msleep to usleep_range for small msecs
From: Linus Walleij @ 2016-11-30 12:19 UTC (permalink / raw)
To: Jonathan Cameron
Cc: Aniroop Mathur, Hartmut Knaack, Lars-Peter Clausen,
Peter Meerwald, linux-iio@vger.kernel.org,
linux-kernel@vger.kernel.org, s.samuel, r.mahale, aniroop.mathur,
Naveen Krishna Chatradhi, Linus Walleij, Vlad Dogaru
In-Reply-To: <fc667b4b-6d40-db6e-3855-7a181fa97458@kernel.org>
On Sun, Nov 27, 2016 at 11:51 AM, Jonathan Cameron <jic23@kernel.org> wrote:
> On 26/11/16 03:47, Aniroop Mathur wrote:
[bmp280.c]
>> /* Wait to make sure we started up properly */
>> - mdelay(data->start_up_time);
>> + usleep_range(data->start_up_time, data->start_up_time + 100);
>
> As this in probe I doubt we really care. Could just set it longer to shut up the warnings.
> Still would like some input from say Linus on this...
Hm, I don't think it's a big issue... this works too it just looks overworked.
On the runtime_resume() path we use msleep() instead which I guess is why
it is not changed in this patch, but they have the same purpose.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH net] vhost_net: don't continue to call the recvmsg when meet errors
From: Yunjian Wang @ 2016-11-30 12:10 UTC (permalink / raw)
To: mst, jasowang, netdev, linux-kernel; +Cc: caihe, wangyunjian
When we meet an error(err=-EBADFD) recvmsg, the error handling in vhost
handle_rx() will continue. This will cause a soft CPU lockup in vhost thread.
Signed-off-by: Yunjian Wang <wangyunjian@huawei.com>
---
drivers/vhost/net.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index 5dc128a..edc470b 100644
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -717,6 +717,9 @@ static void handle_rx(struct vhost_net *net)
pr_debug("Discarded rx packet: "
" len %d, expected %zd\n", err, sock_len);
vhost_discard_vq_desc(vq, headcount);
+ /* Don't continue to do, when meet errors. */
+ if (err < 0)
+ goto out;
continue;
}
/* Supply virtio_net_hdr if VHOST_NET_F_VIRTIO_NET_HDR */
--
1.9.5.msysgit.1
^ permalink raw reply related
* Re: next: Commit 'mm: Prevent __alloc_pages_nodemask() RCU CPU stall ...' causing hang on sparc32 qemu
From: Paul E. McKenney @ 2016-11-30 12:03 UTC (permalink / raw)
To: Guenter Roeck; +Cc: linux-mm, linux-kernel, Andrew Morton, sparclinux, davem
In-Reply-To: <929f6b29-461a-6e94-fcfd-710c3da789e9@roeck-us.net>
On Wed, Nov 30, 2016 at 02:52:11AM -0800, Guenter Roeck wrote:
> On 11/29/2016 11:02 PM, Paul E. McKenney wrote:
> >On Tue, Nov 29, 2016 at 08:32:51PM -0800, Guenter Roeck wrote:
> >>On 11/29/2016 05:28 PM, Paul E. McKenney wrote:
> >>>On Tue, Nov 29, 2016 at 01:23:08PM -0800, Guenter Roeck wrote:
> >>>>Hi Paul,
> >>>>
> >>>>most of my qemu tests for sparc32 targets started to fail in next-20161129.
> >>>>The problem is only seen in SMP builds; non-SMP builds are fine.
> >>>>Bisect points to commit 2d66cccd73436 ("mm: Prevent __alloc_pages_nodemask()
> >>>>RCU CPU stall warnings"); reverting that commit fixes the problem.
And I have dropped this patch. Michal Hocko showed me the error of
my ways with this patch.
Thanx, Paul
> >>>>Test scripts are available at:
> >>>> https://github.com/groeck/linux-build-test/tree/master/rootfs/sparc
> >>>>Test results are at:
> >>>> https://github.com/groeck/linux-build-test/tree/master/rootfs/sparc
> >>>>
> >>>>Bisect log is attached.
> >>>>
> >>>>Please let me know if there is anything I can do to help tracking down the
> >>>>problem.
> >>>
> >>>Apologies!!! Does the patch below help?
> >>>
> >>No, sorry, it doesn't make a difference.
> >
> >Interesting... Could you please send me the build failure messages?
> >
>
> There is no failure message; it just hangs until I abort the qemu session.
>
> http://kerneltests.org/builders/qemu-sparc-next/builds/532/steps/qemubuildcommand/logs/stdio
>
> Guenter
>
> > Thanx, Paul
> >
> >>Guenter
> >>
> >>> Thanx, Paul
> >>>
> >>>------------------------------------------------------------------------
> >>>
> >>>commit 97708e737e2a55fed4bdbc005bf05ea909df6b73
> >>>Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> >>>Date: Tue Nov 29 11:06:05 2016 -0800
> >>>
> >>> rcu: Allow boot-time use of cond_resched_rcu_qs()
> >>>
> >>> The cond_resched_rcu_qs() macro is used to force RCU quiescent states into
> >>> long-running in-kernel loops. However, some of these loops can execute
> >>> during early boot when interrupts are disabled, and during which time
> >>> it is therefore illegal to enter the scheduler. This commit therefore
> >>> makes cond_resched_rcu_qs() be a no-op during early boot.
> >>>
> >>> Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> >>>
> >>>diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
> >>>index 525ca34603b7..b6944cc19a07 100644
> >>>--- a/include/linux/rcupdate.h
> >>>+++ b/include/linux/rcupdate.h
> >>>@@ -423,7 +423,7 @@ extern struct srcu_struct tasks_rcu_exit_srcu;
> >>> */
> >>>#define cond_resched_rcu_qs() \
> >>>do { \
> >>>- if (!cond_resched()) \
> >>>+ if (!is_idle_task(current) && !cond_resched()) \
> >>> rcu_note_voluntary_context_switch(current); \
> >>>} while (0)
> >>>
> >>>diff --git a/include/linux/rcutiny.h b/include/linux/rcutiny.h
> >>>index 7232d199a81c..20f5990deeee 100644
> >>>--- a/include/linux/rcutiny.h
> >>>+++ b/include/linux/rcutiny.h
> >>>@@ -228,6 +228,7 @@ static inline void exit_rcu(void)
> >>>extern int rcu_scheduler_active __read_mostly;
> >>>void rcu_scheduler_starting(void);
> >>>#else /* #ifdef CONFIG_DEBUG_LOCK_ALLOC */
> >>>+#define rcu_scheduler_active false
> >>>static inline void rcu_scheduler_starting(void)
> >>>{
> >>>}
> >>>
> >>>
> >>
> >
> >
>
^ permalink raw reply
* [PATCH 2/2] net: rfkill: Add rfkill-any LED trigger
From: Michał Kępień @ 2016-11-30 12:03 UTC (permalink / raw)
To: Johannes Berg, David S . Miller; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <20161130120317.11851-1-kernel@kempniu.pl>
This patch adds a new "global" (i.e. not per-rfkill device) LED trigger,
rfkill-any, which may be useful for laptops with a single "radio LED"
and multiple radio transmitters. The trigger is meant to turn a LED on
whenever there is at least one radio transmitter active and turn it off
otherwise.
Signed-off-by: Michał Kępień <kernel@kempniu.pl>
---
Note that the search for any active radio will have quadratic complexity
whenever __rfkill_switch_all() is used (as it calls rfkill_set_block()
for every affected rfkill device), but I intentionally refrained from
implementing rfkill_any_led_trigger_event() using struct work_struct to
keep things simple, given the average number of rfkill devices in
hardware these days. Please let me know in case this should be
reworked.
net/rfkill/core.c | 73 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 73 insertions(+)
diff --git a/net/rfkill/core.c b/net/rfkill/core.c
index f28e441..5275f2f 100644
--- a/net/rfkill/core.c
+++ b/net/rfkill/core.c
@@ -176,6 +176,47 @@ static void rfkill_led_trigger_unregister(struct rfkill *rfkill)
{
led_trigger_unregister(&rfkill->led_trigger);
}
+
+static struct led_trigger rfkill_any_led_trigger;
+
+static void __rfkill_any_led_trigger_event(void)
+{
+ enum led_brightness brightness = LED_OFF;
+ struct rfkill *rfkill;
+
+ list_for_each_entry(rfkill, &rfkill_list, node) {
+ if (!(rfkill->state & RFKILL_BLOCK_ANY)) {
+ brightness = LED_FULL;
+ break;
+ }
+ }
+
+ led_trigger_event(&rfkill_any_led_trigger, brightness);
+}
+
+static void rfkill_any_led_trigger_event(void)
+{
+ mutex_lock(&rfkill_global_mutex);
+ __rfkill_any_led_trigger_event();
+ mutex_unlock(&rfkill_global_mutex);
+}
+
+static void rfkill_any_led_trigger_activate(struct led_classdev *led_cdev)
+{
+ rfkill_any_led_trigger_event();
+}
+
+static int rfkill_any_led_trigger_register(void)
+{
+ rfkill_any_led_trigger.name = "rfkill-any";
+ rfkill_any_led_trigger.activate = rfkill_any_led_trigger_activate;
+ return led_trigger_register(&rfkill_any_led_trigger);
+}
+
+static void rfkill_any_led_trigger_unregister(void)
+{
+ led_trigger_unregister(&rfkill_any_led_trigger);
+}
#else
static void rfkill_led_trigger_event(struct rfkill *rfkill)
{
@@ -189,6 +230,19 @@ static inline int rfkill_led_trigger_register(struct rfkill *rfkill)
static inline void rfkill_led_trigger_unregister(struct rfkill *rfkill)
{
}
+
+static void rfkill_any_led_trigger_event(void)
+{
+}
+
+static int rfkill_any_led_trigger_register(void)
+{
+ return 0;
+}
+
+static void rfkill_any_led_trigger_unregister(void)
+{
+}
#endif /* CONFIG_RFKILL_LEDS */
static void rfkill_fill_event(struct rfkill_event *ev, struct rfkill *rfkill,
@@ -297,6 +351,7 @@ static void rfkill_set_block(struct rfkill *rfkill, bool blocked)
spin_unlock_irqrestore(&rfkill->lock, flags);
rfkill_led_trigger_event(rfkill);
+ __rfkill_any_led_trigger_event();
if (prev != curr)
rfkill_event(rfkill);
@@ -477,6 +532,7 @@ bool rfkill_set_hw_state(struct rfkill *rfkill, bool blocked)
spin_unlock_irqrestore(&rfkill->lock, flags);
rfkill_led_trigger_event(rfkill);
+ rfkill_any_led_trigger_event();
if (!rfkill->registered)
return ret;
@@ -523,6 +579,7 @@ bool rfkill_set_sw_state(struct rfkill *rfkill, bool blocked)
schedule_work(&rfkill->uevent_work);
rfkill_led_trigger_event(rfkill);
+ rfkill_any_led_trigger_event();
return blocked;
}
@@ -572,6 +629,7 @@ void rfkill_set_states(struct rfkill *rfkill, bool sw, bool hw)
schedule_work(&rfkill->uevent_work);
rfkill_led_trigger_event(rfkill);
+ rfkill_any_led_trigger_event();
}
}
EXPORT_SYMBOL(rfkill_set_states);
@@ -988,6 +1046,7 @@ int __must_check rfkill_register(struct rfkill *rfkill)
#endif
}
+ __rfkill_any_led_trigger_event();
rfkill_send_events(rfkill, RFKILL_OP_ADD);
mutex_unlock(&rfkill_global_mutex);
@@ -1020,6 +1079,7 @@ void rfkill_unregister(struct rfkill *rfkill)
mutex_lock(&rfkill_global_mutex);
rfkill_send_events(rfkill, RFKILL_OP_DEL);
list_del_init(&rfkill->node);
+ __rfkill_any_led_trigger_event();
mutex_unlock(&rfkill_global_mutex);
rfkill_led_trigger_unregister(rfkill);
@@ -1278,8 +1338,18 @@ static int __init rfkill_init(void)
goto error_input;
#endif
+#ifdef CONFIG_RFKILL_LEDS
+ error = rfkill_any_led_trigger_register();
+ if (error)
+ goto error_led_trigger;
+#endif
+
return 0;
+error_led_trigger:
+#ifdef CONFIG_RFKILL_INPUT
+ rfkill_handler_exit();
+#endif
error_input:
misc_deregister(&rfkill_miscdev);
error_misc:
@@ -1291,6 +1361,9 @@ subsys_initcall(rfkill_init);
static void __exit rfkill_exit(void)
{
+#ifdef CONFIG_RFKILL_LEDS
+ rfkill_any_led_trigger_unregister();
+#endif
#ifdef CONFIG_RFKILL_INPUT
rfkill_handler_exit();
#endif
--
2.10.2
^ permalink raw reply related
* [PATCH 1/2] net: rfkill: Cleanup error handling in rfkill_init()
From: Michał Kępień @ 2016-11-30 12:03 UTC (permalink / raw)
To: Johannes Berg, David S . Miller; +Cc: linux-wireless, netdev, linux-kernel
Use a separate label per error condition in rfkill_init() to make it a
bit cleaner and easier to extend.
Signed-off-by: Michał Kępień <kernel@kempniu.pl>
---
net/rfkill/core.c | 23 ++++++++++++-----------
1 file changed, 12 insertions(+), 11 deletions(-)
diff --git a/net/rfkill/core.c b/net/rfkill/core.c
index 884027f..f28e441 100644
--- a/net/rfkill/core.c
+++ b/net/rfkill/core.c
@@ -1266,24 +1266,25 @@ static int __init rfkill_init(void)
error = class_register(&rfkill_class);
if (error)
- goto out;
+ goto error_class;
error = misc_register(&rfkill_miscdev);
- if (error) {
- class_unregister(&rfkill_class);
- goto out;
- }
+ if (error)
+ goto error_misc;
#ifdef CONFIG_RFKILL_INPUT
error = rfkill_handler_init();
- if (error) {
- misc_deregister(&rfkill_miscdev);
- class_unregister(&rfkill_class);
- goto out;
- }
+ if (error)
+ goto error_input;
#endif
- out:
+ return 0;
+
+error_input:
+ misc_deregister(&rfkill_miscdev);
+error_misc:
+ class_unregister(&rfkill_class);
+error_class:
return error;
}
subsys_initcall(rfkill_init);
--
2.10.2
^ permalink raw reply related
* Re: [PATCH 2/2] ACPI: Ignore Consumer/Producer for QWord/DWord/Word Address Space
From: Lorenzo Pieralisi @ 2016-11-30 12:04 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: linux-pci, linux-acpi, linux-kernel, linux-arm-kernel,
linaro-acpi
In-Reply-To: <20161129184334.7618.5495.stgit@bhelgaas-glaptop.roam.corp.google.com>
On Tue, Nov 29, 2016 at 12:43:34PM -0600, Bjorn Helgaas wrote:
> Per ACPI spec r6.0, sec 6.4.3.5.1, 2, 3, Bit [0] of General Flags (the
> Consumer/Producer bit) should be ignored for QWord/DWord/Word Address Space
> descriptors. The Consumer/Producer bit is defined only for the Extended
> Address Space descriptor.
>
> Ignore Consumer/Producer except for Extended Address Space descriptors.
>
> Note that for QWord/DWord/Word descriptors, we previously applied the
> translation offset (_TRA) only when the Consumer/Producer bit was set.
"..Consumer/Producer bit was clear" ? If that bit was set:
struct acpi_resource_address->producer_consumer == ACPI_CONSUMER
and we are not applying the _TRA offset in that case, right ?
Thanks,
Lorenzo
> This patch changes that: for those descriptors, we ignore Consumer/Producer
> and always apply the translation offset.
>
> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
> ---
> drivers/acpi/resource.c | 16 +++++++++++-----
> 1 file changed, 11 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c
> index 2732d39e..b45cd8f 100644
> --- a/drivers/acpi/resource.c
> +++ b/drivers/acpi/resource.c
> @@ -261,11 +261,16 @@ bool acpi_dev_resource_address_space(struct acpi_resource *ares,
> * primary side. Non-bridge devices must list 0 for all Address
> * Translation offset bits.
> */
> - if (addr->producer_consumer == ACPI_PRODUCER)
> + if (ares->type == ACPI_RESOURCE_TYPE_EXTENDED_ADDRESS64) {
> + if (addr->producer_consumer == ACPI_PRODUCER)
> + offset = attr->translation_offset;
> + else if (attr->translation_offset)
> + pr_debug("ACPI: translation_offset(%lld) is invalid for non-bridge device.\n",
> + attr->translation_offset);
> + } else {
> offset = attr->translation_offset;
> - else if (attr->translation_offset)
> - pr_debug("ACPI: translation_offset(%lld) is invalid for non-bridge device.\n",
> - attr->translation_offset);
> + }
> +
> start = attr->minimum + offset;
> end = attr->maximum + offset;
>
> @@ -294,7 +299,8 @@ bool acpi_dev_resource_address_space(struct acpi_resource *ares,
> return false;
> }
>
> - if (addr->producer_consumer == ACPI_PRODUCER)
> + if (ares->type == ACPI_RESOURCE_TYPE_EXTENDED_ADDRESS64 &&
> + addr->producer_consumer == ACPI_PRODUCER)
> res->flags |= IORESOURCE_WINDOW;
>
> if (addr->info.mem.caching == ACPI_PREFETCHABLE_MEMORY)
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] usb:hub: readibility and consistency in coding style
From: gregkh @ 2016-11-30 12:02 UTC (permalink / raw)
To: Atul Raj
Cc: Viresh Kumar, mathias.nyman@linux.intel.com,
stern@rowland.harvard.edu, baolu.lu@linux.intel.com,
oneukum@suse.com, hansy@nvidia.com, alcooperx@gmail.com,
atulraj.nith@gmail.com, dri-devel@lists.freedesktop.org,
linux-kernel@vger.kernel.org, Pankaj Singh
In-Reply-To: <20161130115139epcms5p3fb0520cf6cabcf69e470be63463a46d1@epcms5p3>
On Wed, Nov 30, 2016 at 11:51:39AM +0000, Atul Raj wrote:
> It is suggested to keep braces if there is a comment in if case as
> comment also takes a line.
> ---
> drivers/usb/core/hub.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Ok, this is getting to be a joke.
Take a few days off, relax, then try to send a patch that works to
yourself first, and run it through scripts/checkpatch.pl to verify that
it really is correct. Hint, this one isn't at all.
Then, maybe you should start doing some work on drivers/staging/ first,
which is where new developers should start out to work out all of these
issues so you don't bother the other developers who are working on
adding new features and fixing bugs.
Also, why are you including a ton of people who have nothing to do with
usb patches on this one?
good luck,
greg k-h
^ permalink raw reply
* Re: [PATCH 00/11] locking/ww_mutex: Keep sorted wait list to avoid stampedes
From: Nicolai Hähnle @ 2016-11-30 11:52 UTC (permalink / raw)
To: Chris Wilson; +Cc: linux-kernel
In-Reply-To: <20161130094034.GM23336@nuc-i3427.alporthouse.com>
On 30.11.2016 10:40, Chris Wilson wrote:
> On Mon, Nov 28, 2016 at 01:20:01PM +0100, Nicolai Hähnle wrote:
>> I've included timings taken from a contention-heavy stress test to some of
>> the patches. The stress test performs actual GPU operations which take a
>> good chunk of the wall time, but even so, the series still manages to
>> improve the wall time quite a bit.
>
> In looking at your contention scenarios, what was the average/max list
> size? Just wondering if it makes sense to use an rbtree + first_waiter
> instead of a sorted list from the start.
I haven't measured this with the new series; previously, while I was
debugging the deadlock on older kernels, I occasionally saw wait lists
of up to ~20 tasks, spit-balling the average over all the deadlock cases
I'd say the average was not more than ~5. The average _without_
deadlocks should be lower, if anything.
I saw that your test cases go quite a bit higher, but even the rather
extreme load I was testing with -- which is not quite a load from an
actual application, though it is related to one -- has 40 threads and so
a theoretical maximum of 40.
Nicolai
> -Chris
>
^ permalink raw reply
* RE: [char-misc-next 4/4 V2] mei: bus: enable non-blocking RX
From: Winkler, Tomas @ 2016-11-30 12:00 UTC (permalink / raw)
To: 'Greg Kroah-Hartman'
Cc: Usyskin, Alexander, 'linux-kernel@vger.kernel.org'
In-Reply-To: <20161130115710.GB1436@kroah.com>
> On Tue, Nov 29, 2016 at 08:09:38PM +0000, Winkler, Tomas wrote:
> >
> > > On Mon, Nov 28, 2016 at 11:03:20PM +0000, Winkler, Tomas wrote:
> > > > >
> > > > >
> > > > > >
> > > > > > On Sat, Nov 19, 2016 at 02:16:11PM +0200, Tomas Winkler wrote:
> > > > > > > From: Alexander Usyskin <alexander.usyskin@intel.com>
> > > > > > >
> > > > > > > Enable non-blocking receive for drivers on mei bus, this
> > > > > > > allows checking for data availability by mei client drivers.
> > > > > > > This is most effective for fixed address clients, that lacks flow
> control.
> > > > > > >
> > > > > > > This function adds new API function
> > > > > > > mei_cldev_recv_nonblock(), it retuns -EGAIN if function will block.
> > > > > > >
> > > > > > > Signed-off-by: Alexander Usyskin
> > > > > > > <alexander.usyskin@intel.com>
> > > > > > > Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
> > > > > > > ---
> > > > > > > V2: use _nonblock() function suffix instead of NONBLOCK flag
> > > > > > >
> > > > > > > drivers/misc/mei/bus-fixup.c | 4 ++--
> > > > > > > drivers/misc/mei/bus.c | 31 +++++++++++++++++++++++++++++-
> -
> > > > > > > drivers/misc/mei/mei_dev.h | 7 ++++++-
> > > > > > > include/linux/mei_cl_bus.h | 6 ++++--
> > > > > > > 4 files changed, 41 insertions(+), 7 deletions(-)
> > > > > > >
> > > > > > > diff --git a/drivers/misc/mei/bus-fixup.c
> > > > > > > b/drivers/misc/mei/bus-fixup.c index
> > > > > > > 7f2cef9011ae..18e05ca7584f
> > > > > > > 100644
> > > > > > > --- a/drivers/misc/mei/bus-fixup.c
> > > > > > > +++ b/drivers/misc/mei/bus-fixup.c
> > > > > > > @@ -141,7 +141,7 @@ static int mei_osver(struct
> > > > > > > mei_cl_device
> > > *cldev)
> > > > > > > if (ret < 0)
> > > > > > > return ret;
> > > > > > >
> > > > > > > - ret = __mei_cl_recv(cldev->cl, buf, length);
> > > > > > > + ret = __mei_cl_recv(cldev->cl, buf, length, 0);
> > > > > >
> > > > > > What is 0 here? Again, mode...
> > > > >
> > > > > Yes, it means no change in behavior, but this is an internal function.
> > >
> > > So, it makes no sense, are you not going to have to read this code
> > > again in 10 years? New developers? Make the code make sense please.
> >
> >
> > Sorry Greg, the code does make sense to me, the whole kernel passes
> > nonblock around as flag starting from the syscall (O_NONBLOCK) it doesn't
> make sense to write two functions that differ in one 'if' statement.
> > I understand that you are in some crusade against flags, but you are not
> proposing a concrete solution and I don't have one either.
> > I can solve it in the external wrapper, but internally it's just a same function.
>
> What is wrong with your email client that it doesn't wrap things properly?
MS Outlook + Exchange.
> Anyway, I don't remember anymore, please resend and I will review it then.
Okay
Tomas
^ permalink raw reply
* RE: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable
From: Hayes Wang @ 2016-11-30 11:58 UTC (permalink / raw)
To: David Miller, mlord@pobox.com
Cc: greg@kroah.com, romieu@fr.zoreil.com, netdev@vger.kernel.org,
nic_swsd, linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org
In-Reply-To: <20161125.115827.2014848246966159357.davem@davemloft.net>
Mark Lord <mlord@pobox.com>
[...]
> > Not sure why, because there really is no other way for the data to
> > appear where it does at the beginning of that URB buffer.
> >
> > This does seem a rather unexpected burden to place upon someone
> > reporting a regression in a USB network driver that corrupts user data.
>
> If you are the only person who can actively reproduce this, which
> seems to be the case right now, this is unfortunately the only way to
> reach a proper analysis and fix.
I have tested it with iperf more than five days without any error.
I would think if there is any other way to reproduce it.
Best Regards,
Hayes
^ permalink raw reply
* Re: [char-misc-next 4/4 V2] mei: bus: enable non-blocking RX
From: 'Greg Kroah-Hartman' @ 2016-11-30 11:57 UTC (permalink / raw)
To: Winkler, Tomas; +Cc: Usyskin, Alexander, 'linux-kernel@vger.kernel.org'
In-Reply-To: <5B8DA87D05A7694D9FA63FD143655C1B54333D99@hasmsx108.ger.corp.intel.com>
On Tue, Nov 29, 2016 at 08:09:38PM +0000, Winkler, Tomas wrote:
>
> > On Mon, Nov 28, 2016 at 11:03:20PM +0000, Winkler, Tomas wrote:
> > > >
> > > >
> > > > >
> > > > > On Sat, Nov 19, 2016 at 02:16:11PM +0200, Tomas Winkler wrote:
> > > > > > From: Alexander Usyskin <alexander.usyskin@intel.com>
> > > > > >
> > > > > > Enable non-blocking receive for drivers on mei bus, this allows
> > > > > > checking for data availability by mei client drivers. This is
> > > > > > most effective for fixed address clients, that lacks flow control.
> > > > > >
> > > > > > This function adds new API function mei_cldev_recv_nonblock(),
> > > > > > it retuns -EGAIN if function will block.
> > > > > >
> > > > > > Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com>
> > > > > > Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
> > > > > > ---
> > > > > > V2: use _nonblock() function suffix instead of NONBLOCK flag
> > > > > >
> > > > > > drivers/misc/mei/bus-fixup.c | 4 ++--
> > > > > > drivers/misc/mei/bus.c | 31 +++++++++++++++++++++++++++++--
> > > > > > drivers/misc/mei/mei_dev.h | 7 ++++++-
> > > > > > include/linux/mei_cl_bus.h | 6 ++++--
> > > > > > 4 files changed, 41 insertions(+), 7 deletions(-)
> > > > > >
> > > > > > diff --git a/drivers/misc/mei/bus-fixup.c
> > > > > > b/drivers/misc/mei/bus-fixup.c index 7f2cef9011ae..18e05ca7584f
> > > > > > 100644
> > > > > > --- a/drivers/misc/mei/bus-fixup.c
> > > > > > +++ b/drivers/misc/mei/bus-fixup.c
> > > > > > @@ -141,7 +141,7 @@ static int mei_osver(struct mei_cl_device
> > *cldev)
> > > > > > if (ret < 0)
> > > > > > return ret;
> > > > > >
> > > > > > - ret = __mei_cl_recv(cldev->cl, buf, length);
> > > > > > + ret = __mei_cl_recv(cldev->cl, buf, length, 0);
> > > > >
> > > > > What is 0 here? Again, mode...
> > > >
> > > > Yes, it means no change in behavior, but this is an internal function.
> >
> > So, it makes no sense, are you not going to have to read this code again in 10
> > years? New developers? Make the code make sense please.
>
>
> Sorry Greg, the code does make sense to me, the whole kernel passes nonblock around as flag starting from the syscall (O_NONBLOCK)
> it doesn't make sense to write two functions that differ in one 'if' statement.
> I understand that you are in some crusade against flags, but you are not proposing a concrete solution and I don't have one either.
> I can solve it in the external wrapper, but internally it's just a same function.
What is wrong with your email client that it doesn't wrap things
properly?
Anyway, I don't remember anymore, please resend and I will review it
then.
greg k-h
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox