linaro-dev

linaro-dev@lists.linaro.org

4332 discussions

[PATCH PMQA] thermal: skip if there are no cooling devices

by Sanjay Singh Rawat

Signed-off-by: Sanjay Singh Rawat <sanjay.rawat(a)linaro.org> --- include/thermal_functions.sh | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/include/thermal_functions.sh b/include/thermal_functions.sh index 1f1991f..0c836c5 100644 --- a/include/thermal_functions.sh +++ b/include/thermal_functions.sh @@ -163,6 +163,10 @@ for_each_cooling_device() { shift 1 devices=$(ls $THERMAL_PATH | grep "cooling_device['$MAX_CDEV']") + if [ "$devices" == "" ]; then + log_skip "no cooling devices" + return 0 + fi ALL_DEVICE=$devices for device in $devices; do -- 1.8.3.2

10 years, 10 months

[Activity] week 27

by Vishal Bhoj

== Progress == * Juno Android release (CARD-1104, 40%) * Closed u-boot ARMv8 Android build (CARD-1049, 10%) == Plans == * Android Baseline maintenance * Reduce the number of FVP Android builds. * Move Juno daily builds to public location. == Issues == None Regards, Vishal

10 years, 10 months

[Activity] week 27

by Koen Kooi

== Progress == * OE baseline work (CARD-787: 60%) * GCC 4.9 BE update * Juno (40%) == Plans == * OE toolchain updates == Issues == -- Koen Kooi Builds and Baselines | Release Manager Linaro.org | Open source software for ARM SoCs

10 years, 10 months

[Activity] week 26

by Koen Kooi

== Progress == * OE baseline work (CARD-787: 10%) * Release 90% == Plans == * Release Juno == Issues == * ITS broke releases.l.o and snapshots.l.o -- Koen Kooi Builds and Baselines | Release Manager Linaro.org | Open source software for ARM SoCs

10 years, 10 months

[Activity] week 25

by Koen Kooi

== Progress == * OE baseline work (CARD-787: 100%) * OE-core binconfig fixes == Plans == * Release == Issues == -- Koen Kooi Builds and Baselines | Release Manager Linaro.org | Open source software for ARM SoCs

10 years, 10 months

[Activity] week 24

by Koen Kooi

== Progress == * OE baseline work (CARD-787: 80%) * ODP work * Patch review * Juno CI loop (CARD-1441: 20%) -- Koen Kooi Builds and Baselines | Release Manager Linaro.org | Open source software for ARM SoCs

10 years, 10 months

Regarding powertop VFS ops/sec output

by Mohammad Merajul Islam Molla

Hello, It looks like powertop requires a kernel patch to display VFS ops/sec. The last patch was for kernel v3.3.0. The patch needs to be updated, otherwise powertop always displays 0 VFS ops/sec. Considering changes starting with kernel v3.9, the kernel side patch would look like as below. I have tested it with powertop and linux-linaro-tracking branch (v3.14.0) and with this patch powertop displays and updates VFS ops/sec properly. diff --git a/fs/fs-writeback.c b/fs/fs-writeback.c index 5584bea..c6a9832 100644 --- a/fs/fs-writeback.c +++ b/fs/fs-writeback.c @@ -1141,6 +1141,9 @@ void __mark_inode_dirty(struct inode *inode, int flags) if ((inode->i_state & flags) == flags) return; + if (flags & (I_DIRTY_SYNC | I_DIRTY_DATASYNC | I_DIRTY_PAGES)) + trace_writeback_inode_dirty(inode, flags); + if (unlikely(block_dump > 1)) block_dump___mark_inode_dirty(inode); diff --git a/include/trace/events/writeback.h b/include/trace/events/writeback.h index 464ea82..7956d8f 100644 --- a/include/trace/events/writeback.h +++ b/include/trace/events/writeback.h @@ -101,6 +101,35 @@ DEFINE_EVENT(writeback_dirty_inode_template, writeback_dirty_inode, TP_ARGS(inode, flags) ); +/* + * Tracepoint for dirtying an inode; used by PowerTOP + */ +TRACE_EVENT(writeback_inode_dirty, + + TP_PROTO(struct inode *inode, int flags), + + TP_ARGS(inode, flags), + + TP_STRUCT__entry( + __field( __kernel_dev_t, dev ) + __field( ino_t, ino ) + __field( u32, flags ) + ), + + TP_fast_assign( + __entry->dev = inode->i_sb->s_dev; + __entry->ino = inode->i_ino; + __entry->flags = flags; + ), + + TP_printk("dev %d:%d ino %lu flags %d %s", MAJOR(__entry->dev), + MINOR(__entry->dev), + (unsigned long) __entry->ino, + __entry->flags, + show_inode_state(__entry->flags) + ) +); + DECLARE_EVENT_CLASS(writeback_write_inode_template, TP_PROTO(struct inode *inode, struct writeback_control *wbc), However, there is an alternative thought. Starting with kernel v3.9, kernel provides a built in trace event called - "writeback_dirty_inode" - DEFINE_EVENT(writeback_dirty_inode_template, writeback_dirty_inode, TP_PROTO(struct inode *inode, int flags), TP_ARGS(inode, flags) ); But since the event powertop expects is "writeback_inode_dirty" and the names and output format don't match, to take advantage of the built-in kernel trace event, the below two patches together make it work. powertop side patch is necessary to match the TRACE_EVENT name. Also, checking for dev > 0 is not necessary, since now there is name instead of device major and minor number in kernel trace. kernel side patch is necessary to account for DIRTY_PAGES. powertop side patch - diff --git a/src/process/do_process.cpp b/src/process/do_process.cpp index ba164eb..2e2cbea 100644 --- a/src/process/do_process.cpp +++ b/src/process/do_process.cpp @@ -625,21 +625,14 @@ void perf_process_bundle::handle_trace_point(void *trace, int cpu, uint64_t time consumer->gpu_ops++; } } - else if (strcmp(event->name, "writeback_inode_dirty") == 0) { - static uint64_t prev_time; + else if (strcmp(event->name, "writeback_dirty_inode") == 0) { + static uint64_t prev_time = 0; class power_consumer *consumer = NULL; - int dev; consumer = current_consumer(cpu); - ret = pevent_get_field_val(NULL, event, "dev", &rec, &val, 0); - if (ret < 0) - - return; - dev = (int)val; - if (consumer && strcmp(consumer->name(), - "process")==0 && dev > 0) { + "process")==0) { consumer->disk_hits++; @@ -674,7 +667,7 @@ void start_process_measurement(void) perf_events->add_event("workqueue:workqueue_execute_end"); perf_events->add_event("i915:i915_gem_ring_dispatch"); perf_events->add_event("i915:i915_gem_request_submit"); - perf_events->add_event("writeback:writeback_inode_dirty"); + perf_events->add_event("writeback:writeback_dirty_inode"); } first_stamp = ~0ULL; kernel side patch - diff --git a/fs/fs-writeback.c b/fs/fs-writeback.c index 5584bea..c2ab700 100644 --- a/fs/fs-writeback.c +++ b/fs/fs-writeback.c @@ -1141,6 +1141,9 @@ void __mark_inode_dirty(struct inode *inode, int flags) if ((inode->i_state & flags) == flags) return; + if (flags & I_DIRTY_PAGES) + trace_writeback_dirty_inode(inode, flags); + if (unlikely(block_dump > 1)) block_dump___mark_inode_dirty(inode); I have tested both solutions and both displays and updates VFS ops/sec. However, since second solution changes powertop, that means powertop won't work with pre v3.9 kernel. Any comment or thought on this? -- Thanks, -Meraj

10 years, 10 months

[ACTIVITY] week 27

by Dileep Katta

== Progress == * Enabling UEFI Fastboot on Panda - on hold (CARD-198: 0 %) * CARD 1103: Flash support on u-boot fastboot, downlload of image is working in case of Flash command. Shared the code with Andrey (CARD-1103: 60%) * CARD 1103: Flash support on u-boot fastboot, Adding DFU APIs is in progress (CARD-1103: 40%) == Plans == * CARD-198: Pause (0%) * CARD 1103: Flash support on u-boot fastboot, Add DFU code and submit for review, re-order the functionality as per review comments (CARD-1103: 100%) == Issues == * None

10 years, 10 months

detecting long multiply overflow

by Edward Nevill

Hi, Does anyone know of a nice way to detect 64 x 64 -> 64 multiply overflow on aarch64? On x86 you can just use the V flag, but aarch64 seems to have no option to set the flags after a MUL instruction which I find very odd. The only solution I can think of is to do the equivalent of r = a * b; if (r/a != b) overflow(); There is some short circuiting you can do to avoid the div if you know there is no possibility it could have overflowed. Eg. if (clz(labs(a)) + clz(labs(b)) < 32) { r = a * b; if (r/a != b) overflow(); } Then there is the special case of a = 0x8000000000000000 and b == -1. All in all its a mess just to detect overflow. Regards, Ed.

10 years, 10 months

[ACTIVITY] week 27

by Bernhard Rosenkränzer

== Progress == * More Bionic optimizations * Installed Android L preview on my Nexus 7, looked at the GPL code bits that were released * Code review+different approach for zlib optimizations * Checked upstream git for indications of how the NDK will handle 64bit systems (but the related code isn't there yet) == Plans == * Start cbuildv2 toolchain builds for testing * Restore Galaxy Nexus support * Check if the new aarch64 strchr in glibc 2014.07 can be reused in Bionic * Follow up on zlib optimizations etc. == Issues == * ci.linaro.org is broken

10 years, 10 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-dev