RE: [Oops][next-20170614][] powerpc boot fails with WARNING: CPU: 12 PID: 0 at mm/memblock.c
On Thursday, June 15, 2017 2:25 AM, Abdul Haleem [mailto:abdha...@linux.vnet.ibm.com] wrote: > > On Thu, 2017-06-15 at 11:30 +0530, Abdul Haleem wrote: >> Hi, >> >> linux-next fails to boot on powerpc Bare-metal with these warnings. >> >> machine booted fine on next-20170613 > > Thanks Michael, Yes it is (75fe04e59 of: remove *phandle properties from > expanded device tree) > > Frank, would you please take a look at the trace. > > Thanks < snip > My patch series 'of: remove *phandle properties from expanded device tree' in -next seems to have broken boot for a significant number of powerpc systems. I am actively working on understanding and fixing the problem. -Frank
RE: [PATCH] of: undeclared variable when CONFIG_DEBUG_LOCK_ALLOC
On Monday, May 01, 2017 1:13 PM, Rob Herring [mailto:robh...@kernel.org] wrote: > > On Sun, Apr 30, 2017 at 3:00 PM, Frank Rowand > wrote: >> An undeclared variable was used in a macro that evaluates to nothing >> when CONFIG_DEBUG_LOCK_ALLOC is not defined. Change to use the correct >> variable that does exist. >> >> --- >> >> reported by kbuild test robot on on robh/for-next >>https://lkml.org/lkml/2017/4/29/134 > > That's a bit misleading because I've not applied the offending patch. > Please squash this. > > Rob Does "squash this" mean to redo the original path to include this fix? Thanks, Frank
Invitation and RFC: Linux Plumbers Device Tree track proposed
In recent years there have been proposed tools to aid in the creation of valid device trees and in debugging device tree issues. An example of this is the various approaches proposed (with source code provided) to validate device tree source against valid bindings. As of today, device tree related tools, techniques, and debugging infrastructure have not progressed very far. I have submitted a device tree related proposal for the Linux Plumbers 2015 conference to spur action and innovation in such tools, techniques, and debugging infrastructure. The current title of the track is "Device Tree Tools, Validation, and Troubleshooting". The proposal is located at http://wiki.linuxplumbersconf.org/2015:device_tree_tools_validation_and_trouble_shooting I am looking for several things at the moment: 1) Suggestions of additional topics to be discussed. 2) Emails or other messages expressing an interest in attending the device tree track. 3) Commitments to attend the device tree track (the conference committee is looking at attendee interest and commitments as part of the process of accepting the device tree track). 4) Identifying additional people who should attend the device tree track. The desired outcome of the device tree track is to encourage the future development of tools, process, etc to make device tree related development, test, review and system administration more efficient, faster, easier, more robust, and to improve troubleshooting and debugging facilities. Some examples of areas of interest could include: - make it easier to create correct device tree source files - support for debugging incorrect device tree source files - create a kernel that correctly boots one or more specific device trees (eg a kernel configured to include the proper drivers and subsystems) - create drivers that properly work for a device tree binding definition - create drivers that support detecting errors in the related node(s) in a device tree The wiki page lists additional areas of interest. Thanks, Frank Rowand Sony Mobile Communications -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Bench for testing scheduler
On Thursday, November 07, 2013 9:42 AM, Morten Rasmussen
[morten.rasmus...@arm.com] wrote:
>
> Hi Vincent,
>
> On Thu, Nov 07, 2013 at 10:54:30AM +, Vincent Guittot wrote:
> > Hi,
> >
> > During the Energy-aware scheduling mini-summit, we spoke about benches
> > that should be used to evaluate the modifications of the scheduler.
> > I’d like to propose a bench that uses cyclictest to measure the wake
> > up latency and the power consumption. The goal of this bench is to
> > exercise the scheduler with various sleeping period and get the
> > average wakeup latency. The range of the sleeping period must cover
> > all residency times of the idle state table of the platform. I have
> > run such tests on a tc2 platform with the packing tasks patchset.
> > I have use the following command:
> > #cyclictest -t -q -e 1000 -i <500-12000> -d 150 -l
> > 2000
>
> I think cyclictest is a useful model small(er) periodic tasks for
> benchmarking energy related patches. However, it doesn't have a
> good-enough-performance criteria as it is. I think that is a strict
> requirement for all energy related benchmarks.
>
> Measuring latency gives us a performance metric while the energy tells
> us how energy efficient we are. But without a latency requirement we
> can't really say if a patch helps energy-awareness unless it improves
> both energy _and_ performance. That is the case for your packing patches
> for this particular benchmark with this specific configuration. That is
> a really good result. However, in the general case patches may trade a
> bit of performance to get better energy, which is also good if
> performance still meets the requirement of the application/user. So we
> need a performance criteria to tells us when we sacrifice too much
> performance when trying to save power. Without it it is just a
> performance benchmark where we measure power.
>
> Coming up with a performance criteria for cyclictest is not so easy as
> it doesn't really model any specific application. I guess sacrificing a
> bit of latency is acceptable if it comes with significant energy
> savings. But a huge performance impact might not be, even if it comes
> with massive energy savings. So maybe the criteria would consist of both
> a minimum latency requirement (e.g. up to 10% increase) and a
> requirement for improved energy per work.
>
> As I see it, it the only way we can validate energy efficiency of
> patches that trade performance for improved energy.
I think those comments capture some of the additional complexity of
the power vs performance tradeoff that need to be considered.
One thing not well-defined is what "performance" is. The session at the
kernel discussed throughput and latency. I'm not sure if people are
combining two different things into the name of latency. To me, latency
is wake up latency; the elapsed time from when an event occurred to when
the process handling the event is executing instructions (where I think of
the process typically as user space code, but it could sometimes instead
be kernel space code). The second thing people might think of as latency
is how long from the triggering event until when work is completed on
behalf of the consumer event (where the consumer could be a machine, but
is often a human being, eg if a packet from google arrives, how long until
I see the search result on my screen). This second thing I call response time.
Then "wake up latency" is also probably a mis-nomer. The cyclictest wake up
latency ends when the cyclictest thread is both woken, and then is actually
executing code on the cpu ("running").
Wake up latency is a fine thing to focus on (especially since power management
can have a large impact on wake up latency) but I hope we remember to pay
attention to response time as one of the important performance metrics.
Onward to cyclictest... Cyclictest is commonly referred to as a benchmark
(which it is), but it is at the core more like instrumentation, providing
a measure of some types of wake up latency. Cyclictest is normally used
in conjunction with a separate workload. (Even though cyclictest has
enough tuning knobs that it can also be used as a workload.) There are some
ways that perf and cyclictest can be compared as sources of performance data:
- cyclictest
- Measures wake up latency of only cyclictest threads.
- Captures _entire_ latency, including coming out of low power mode to
service the (timer) interrupt that results in the task wake up.
- perf sched
- Measures all processes (this can be sliced and diced in post-processing
to include any desired set of processes).
- Captures latency from when task is _woken_ to when task is _executing code_
on a cpu.
I think both cyclictest and perf sched are valuable tools, that can each
contribute to understanding system behavior.
-Frank--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kern
RE: Bench for testing scheduler
On Friday, November 08, 2013 1:28 AM, Vincent Guittot
[vincent.guit...@linaro.org] wrote:
>
> On 8 November 2013 01:04, Rowand, Frank wrote:
> > Hi Vincent,
> >
> > Thanks for creating some benchmark numbers!
>
> you're welcome
>
> >
> >
> > On Thursday, November 07, 2013 5:33 AM, Vincent Guittot
> > [vincent.guit...@linaro.org] wrote:
> >>
> >> On 7 November 2013 12:32, Catalin Marinas wrote:
> >> > Hi Vincent,
> >> >
> >> > (for whatever reason, the text is wrapped and results hard to read)
> >>
> >> Yes, i have just seen that. It looks like gmail has wrapped the lines.
> >> I have added the results which should not be wrapped, at the end of this
> >> email
> >>
> >> >
> >> >
> >> > On Thu, Nov 07, 2013 at 10:54:30AM +, Vincent Guittot wrote:
> >> >> During the Energy-aware scheduling mini-summit, we spoke about benches
> >> >> that should be used to evaluate the modifications of the scheduler.
> >> >> I’d like to propose a bench that uses cyclictest to measure the wake
> >> >> up latency and the power consumption. The goal of this bench is to
> >> >> exercise the scheduler with various sleeping period and get the
> >> >> average wakeup latency. The range of the sleeping period must cover
> >> >> all residency times of the idle state table of the platform. I have
> >> >> run such tests on a tc2 platform with the packing tasks patchset.
> >> >> I have use the following command:
> >> >> #cyclictest -t -q -e 1000 -i <500-12000> -d 150
> >> >> -l 2000
> >
> > The number of loops ("-l 2000") should be much larger to create useful
> > results. I don't have a specific number that is large enough, I just
> > know from experience that 2000 is way too small. For example, running
> > cyclictest several times with the same values on my laptop gives values
> > that are not consistent:
>
> The Avg figures look almost stable IMO. Are you speaking about the Max
> value for the inconsistency ?
The values on my laptop for "-l 2000" are not stable.
If I collapse all of the threads in each of the following tests to a
single value I get the following table. Note that each thread completes
a different number of cycles, so I calculate the average as:
total count = T0_count + T1_count + T2_count + T3_count
avg = ( (T0_count * T0_avg) + (T1_count * T1_avg) + ... + (T3_count * T3_avg)
) / total count
min is the smallest min for any of the threads
max is the largest max for any of the threads
total
test Tcount min avg max
--- --- -
1 4 5886276.0 1017
2 4 5881271.5 810
3 4 5885274.2 1143
4 4 5884268.9 1279
test 1 average is 10% larger than test 4.
test 4 maximum is 50% larger than test2.
But all of this is just a minor detail of how to run cyclictest. The more
important question is whether to use cyclictest results as a valid workload
or metric, so for the moment I won't comment further on the cyclictest
parameters you used to collect the example data you provided.
>
> >
> >$ sudo ./cyclictest -t -q -e 1000 -i 500 -d 150 -l 2000
> ># /dev/cpu_dma_latency set to 1000us
> >T: 0 ( 9703) P: 0 I:500 C: 2000 Min: 2 Act: 90 Avg: 77 Max:
> > 243
> >T: 1 ( 9704) P: 0 I:650 C: 1557 Min: 2 Act: 58 Avg: 68 Max:
> > 226
> >T: 2 ( 9705) P: 0 I:800 C: 1264 Min: 2 Act: 54 Avg: 81 Max:
> > 1017
> >T: 3 ( 9706) P: 0 I:950 C: 1065 Min: 2 Act: 11 Avg: 80 Max:
> > 260
> >
> >$ sudo ./cyclictest -t -q -e 1000 -i 500 -d 150 -l 2000
> ># /dev/cpu_dma_latency set to 1000us
> >T: 0 ( 9709) P: 0 I:500 C: 2000 Min: 2 Act: 45 Avg: 74 Max:
> > 390
> >T: 1 ( 9710) P: 0 I:650 C: 1554 Min: 2 Act: 82 Avg: 61 Max:
> > 810
> >T: 2 ( 9711) P: 0 I:800 C: 1263 Min: 2 Act: 83 Avg: 74 Max:
> > 287
> >T: 3 ( 9712) P: 0 I:950 C: 1064 Min: 2 Act: 103 Avg: 79 Max:
> > 551
> >
> >$ sudo ./cyclictest -t -q -e 1000 -i 500 -d 150 -l 2000
> ># /dev/cpu_dma_latency set to 1000us
> >T: 0 ( 9716) P: 0 I:500 C: 2000 Min: 2 Act: 82 Avg: 72 Max:
> > 252
> >T: 1 ( 9717) P: 0 I:650 C: 1556 Min: 2 Act: 115 Avg: 77 Max:
> > 354
> >T: 2 ( 9718) P: 0 I:800 C: 12
RE: Bench for testing scheduler
Hi Vincent,
Thanks for creating some benchmark numbers!
On Thursday, November 07, 2013 5:33 AM, Vincent Guittot
[vincent.guit...@linaro.org] wrote:
>
> On 7 November 2013 12:32, Catalin Marinas wrote:
> > Hi Vincent,
> >
> > (for whatever reason, the text is wrapped and results hard to read)
>
> Yes, i have just seen that. It looks like gmail has wrapped the lines.
> I have added the results which should not be wrapped, at the end of this email
>
> >
> >
> > On Thu, Nov 07, 2013 at 10:54:30AM +, Vincent Guittot wrote:
> >> During the Energy-aware scheduling mini-summit, we spoke about benches
> >> that should be used to evaluate the modifications of the scheduler.
> >> I’d like to propose a bench that uses cyclictest to measure the wake
> >> up latency and the power consumption. The goal of this bench is to
> >> exercise the scheduler with various sleeping period and get the
> >> average wakeup latency. The range of the sleeping period must cover
> >> all residency times of the idle state table of the platform. I have
> >> run such tests on a tc2 platform with the packing tasks patchset.
> >> I have use the following command:
> >> #cyclictest -t -q -e 1000 -i <500-12000> -d 150 -l
> >> 2000
The number of loops ("-l 2000") should be much larger to create useful
results. I don't have a specific number that is large enough, I just
know from experience that 2000 is way too small. For example, running
cyclictest several times with the same values on my laptop gives values
that are not consistent:
$ sudo ./cyclictest -t -q -e 1000 -i 500 -d 150 -l 2000
# /dev/cpu_dma_latency set to 1000us
T: 0 ( 9703) P: 0 I:500 C: 2000 Min: 2 Act: 90 Avg: 77 Max:
243
T: 1 ( 9704) P: 0 I:650 C: 1557 Min: 2 Act: 58 Avg: 68 Max:
226
T: 2 ( 9705) P: 0 I:800 C: 1264 Min: 2 Act: 54 Avg: 81 Max:
1017
T: 3 ( 9706) P: 0 I:950 C: 1065 Min: 2 Act: 11 Avg: 80 Max:
260
$ sudo ./cyclictest -t -q -e 1000 -i 500 -d 150 -l 2000
# /dev/cpu_dma_latency set to 1000us
T: 0 ( 9709) P: 0 I:500 C: 2000 Min: 2 Act: 45 Avg: 74 Max:
390
T: 1 ( 9710) P: 0 I:650 C: 1554 Min: 2 Act: 82 Avg: 61 Max:
810
T: 2 ( 9711) P: 0 I:800 C: 1263 Min: 2 Act: 83 Avg: 74 Max:
287
T: 3 ( 9712) P: 0 I:950 C: 1064 Min: 2 Act: 103 Avg: 79 Max:
551
$ sudo ./cyclictest -t -q -e 1000 -i 500 -d 150 -l 2000
# /dev/cpu_dma_latency set to 1000us
T: 0 ( 9716) P: 0 I:500 C: 2000 Min: 2 Act: 82 Avg: 72 Max:
252
T: 1 ( 9717) P: 0 I:650 C: 1556 Min: 2 Act: 115 Avg: 77 Max:
354
T: 2 ( 9718) P: 0 I:800 C: 1264 Min: 2 Act: 59 Avg: 78 Max:
1143
T: 3 ( 9719) P: 0 I:950 C: 1065 Min: 2 Act: 104 Avg: 70 Max:
238
$ sudo ./cyclictest -t -q -e 1000 -i 500 -d 150 -l 2000
# /dev/cpu_dma_latency set to 1000us
T: 0 ( 9722) P: 0 I:500 C: 2000 Min: 2 Act: 82 Avg: 68 Max:
213
T: 1 ( 9723) P: 0 I:650 C: 1555 Min: 2 Act: 65 Avg: 65 Max:
1279
T: 2 ( 9724) P: 0 I:800 C: 1264 Min: 2 Act: 91 Avg: 69 Max:
244
T: 3 ( 9725) P: 0 I:950 C: 1065 Min: 2 Act: 58 Avg: 76 Max:
242
> >
> > cyclictest could be a good starting point but we need to improve it to
> > allow threads of different loads, possibly starting multiple processes
> > (can be done with a script), randomly varying load threads. These
> > parameters should be loaded from a file so that we can have multiple
> > configurations (per SoC and per use-case). But the big risk is that we
> > try to optimise the scheduler for something which is not realistic.
>
> The goal of this simple bench is to measure the wake up latency and the
> reachable value of the scheduler on a platform but not to emulate a "real"
> use case. In the same way than sched-pipe tests a specific behavior of the
> scheduler, this bench tests the wake up latency of a system.
>
> Starting multi processes and adding some loads can also be useful but the
> target will be a bit different from wake up latency. I have one concern with
> randomness because it prevents from having repeatable and comparable tests
> and results.
>
> I agree that we have to test "real" use cases but it doesn't prevent from
> testing the limit of a characteristic on a system
>
> >
> >
> > We are working on describing some basic scenarios (plain English for
> > now) and one of them could be video playing with threads for audio and
> > video decoding with random change in the workload.
> >
> > So I think the first step should be a set of tools/scripts to analyse
> > the scheduler behaviour, both in terms of latency and power, and these
> > can use perf sched. We can then run some real life scenarios (e.g.
> > Android video playback) and build a benchmark that matches such
> > behaviour as close as possible. We can probably use (o
RE: [PATCH] lost softirq, 2.6.24-rc7
Steve, You are totally correct. I used the wrong words when I said "ksoftirqd thread runs". My apologies for very misleading wording. I have updated the wording in-line below, in the original message to indicate that it is softirq threads, in the ksoftirqd() function, not the ksoftirqd thread. -Frank -Original Message- From: Steven Rostedt [mailto:[EMAIL PROTECTED] Sent: Tue 1/15/2008 4:39 PM To: Rowand, Frank Cc: linux-kernel@vger.kernel.org; [EMAIL PROTECTED] Subject: Re: [PATCH] lost softirq, 2.6.24-rc7 On Tue, Jan 15, 2008 at 02:15:26PM -0800, Frank Rowand wrote: > From: Frank Rowand <[EMAIL PROTECTED]> > > (Ingo, there is a question for you after the description, just before the > patch.) > > When running an interrupt and network intensive stress test with PREEMPT_RT > enabled, the target system stopped processing received network packets. > skbs from received packets were being queued by net_rx_action(), but the > NET_RX_SOFTIRQ softirq was never running to remove the skbs from the queue. > Since the target system root file system is NFS mounted, the system is now > effectively hung. > > A pseudocode description of how this state was reached follows. > Each level of indentation represents a function call from the previous line. > > > ethernet driver irq handler receives packet >netif_rx() > queues skb (qlen == 1), raises NET_RX_SOFTIRQ > > on return from irq >___do_softirq() [ 1 ] > Reset the pending bitmask Frank, This path should not be hit when running with PREEMPT_RT. The softirqs are now all separate, and are not run in batch in ksoftirqd. In fact, ksoftirqd should not be running at all with PREEMPT_RT. -- Steve > net_rx_action() > dequeues skb (qlen == 0) > jiffies incremented, so > break out of processing > and raise NET_RX_SOFTIRQ > (but don't deassert NAPI_STATE_SCHED) > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > - > ksoftirqd thread runs ^^ should have been: the TIMER_SOFTIRQ and RCU_SOFTIRQ softirq threads, which are both executing ksoftirqd() run > process TIMER_SOFTIRQ > process RCU_SOFTIRQ > << ksoftirqd sleeps >> ^^^ should have been: the softirq threads, executing in ksoftirqd(), sleep > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > - > > ___do_softirq() [ 2 ] > Reset the pending bitmask > finds NET_RX_SOFTIRQ raised but already running > << ___do_softirq() [ 2 ] completes >> > > << ___do_softirq() [ 1 ] resumes >> > the pending bitmask is empty, so NET_RX_SOFTIRQ is lost > > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 3/4] RT: remove finish_arch_switch
Steve,
Thanks, I'll bring this up over on the linux-mips list to see how they
really want to handle it.
-Frank
-Original Message-
From: Steven Rostedt [mailto:[EMAIL PROTECTED]
Sent: Tue 1/15/2008 6:14 PM
To: Rowand, Frank
Cc: linux-kernel@vger.kernel.org; [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: [PATCH 3/4] RT: remove finish_arch_switch
On Tue, Jan 15, 2008 at 02:20:46PM -0800, Frank Rowand wrote:
> From: Frank Rowand <[EMAIL PROTECTED]>
>
>
> Index: linux-2.6.24-rc7/include/asm-mips/mach-tx49xx/cpu-feature-overrides.h
> ===
> --- linux-2.6.24-rc7.orig/include/asm-mips/mach-tx49xx/cpu-feature-overrides.h
> +++ linux-2.6.24-rc7/include/asm-mips/mach-tx49xx/cpu-feature-overrides.h
> @@ -1,6 +1,13 @@
> #ifndef __ASM_MACH_TX49XX_CPU_FEATURE_OVERRIDES_H
> #define __ASM_MACH_TX49XX_CPU_FEATURE_OVERRIDES_H
>
> +/* finish_arch_switch_empty is defined if we know finish_arch_switch() will
> + * be empty, based on the lack of features defined in this file. This is
> + * needed because config preempt will barf in kernel/sched.c ifdef
> + * finish_arch_switch
> + */
> +#define finish_arch_switch_empty
> +
> #define cpu_has_llsc 1
> #define cpu_has_64bits 1
> #define cpu_has_inclusive_pcaches0
> Index: linux-2.6.24-rc7/include/asm-mips/system.h
> ===
> --- linux-2.6.24-rc7.orig/include/asm-mips/system.h
> +++ linux-2.6.24-rc7/include/asm-mips/system.h
> @@ -70,6 +70,8 @@ do {
> \
> (last) = resume(prev, next, task_thread_info(next));\
> } while (0)
>
> +/* preempt kernel barfs in kernel/sched.c ifdef finish_arch_switch */
> +#ifndef finish_arch_switch_empty
I'll take this patch for now, but currently it looks like a hack. I know
you said that, but I'm hoping someone will come up with a better
solution.
Thanks,
-- Steve
> #define finish_arch_switch(prev) \
> do { \
> if (cpu_has_dsp)\
> @@ -77,6 +79,7 @@ do {
> \
> if (cpu_has_userlocal) \
> write_c0_userlocal(current_thread_info()->tp_value);\
> } while (0)
> +#endif
>
> static inline unsigned long __xchg_u32(volatile int * m, unsigned int val)
> {
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
