You can subscribe to this list here.
2001 |
Jan
(1) |
Feb
|
Mar
(7) |
Apr
(3) |
May
(3) |
Jun
(7) |
Jul
(10) |
Aug
(1) |
Sep
(50) |
Oct
(74) |
Nov
(28) |
Dec
(32) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
(63) |
Feb
(27) |
Mar
(88) |
Apr
(21) |
May
(59) |
Jun
(41) |
Jul
(61) |
Aug
(89) |
Sep
(179) |
Oct
(152) |
Nov
(190) |
Dec
(92) |
2003 |
Jan
(140) |
Feb
(160) |
Mar
(193) |
Apr
(107) |
May
(84) |
Jun
(60) |
Jul
(97) |
Aug
(97) |
Sep
(42) |
Oct
(105) |
Nov
(99) |
Dec
(52) |
2004 |
Jan
(99) |
Feb
(97) |
Mar
(62) |
Apr
(73) |
May
(94) |
Jun
(37) |
Jul
(32) |
Aug
(89) |
Sep
(87) |
Oct
(72) |
Nov
(114) |
Dec
(35) |
2005 |
Jan
(25) |
Feb
(42) |
Mar
(120) |
Apr
(151) |
May
(71) |
Jun
(36) |
Jul
(35) |
Aug
(92) |
Sep
(19) |
Oct
(57) |
Nov
(77) |
Dec
(61) |
2006 |
Jan
(107) |
Feb
(114) |
Mar
(66) |
Apr
(101) |
May
(74) |
Jun
(64) |
Jul
(42) |
Aug
(51) |
Sep
(106) |
Oct
(118) |
Nov
(138) |
Dec
(162) |
2007 |
Jan
(148) |
Feb
(222) |
Mar
(73) |
Apr
(160) |
May
(166) |
Jun
(125) |
Jul
(184) |
Aug
(58) |
Sep
(41) |
Oct
(102) |
Nov
(111) |
Dec
(52) |
2008 |
Jan
(104) |
Feb
(67) |
Mar
(48) |
Apr
(125) |
May
(114) |
Jun
(98) |
Jul
(206) |
Aug
(89) |
Sep
(88) |
Oct
(163) |
Nov
(115) |
Dec
(113) |
2009 |
Jan
(131) |
Feb
(85) |
Mar
(157) |
Apr
(198) |
May
(202) |
Jun
(154) |
Jul
(156) |
Aug
(75) |
Sep
(80) |
Oct
(148) |
Nov
(88) |
Dec
(83) |
2010 |
Jan
(78) |
Feb
(59) |
Mar
(89) |
Apr
(54) |
May
(92) |
Jun
(66) |
Jul
(38) |
Aug
(73) |
Sep
(84) |
Oct
(91) |
Nov
(52) |
Dec
(62) |
2011 |
Jan
(86) |
Feb
(68) |
Mar
(129) |
Apr
(121) |
May
(154) |
Jun
(81) |
Jul
(55) |
Aug
(55) |
Sep
(58) |
Oct
(115) |
Nov
(88) |
Dec
(95) |
2012 |
Jan
(105) |
Feb
(62) |
Mar
(52) |
Apr
(54) |
May
(103) |
Jun
(89) |
Jul
(152) |
Aug
(73) |
Sep
(58) |
Oct
(60) |
Nov
(52) |
Dec
(90) |
2013 |
Jan
(102) |
Feb
(63) |
Mar
(68) |
Apr
(128) |
May
(82) |
Jun
(94) |
Jul
(87) |
Aug
(29) |
Sep
(24) |
Oct
(25) |
Nov
(40) |
Dec
(51) |
2014 |
Jan
(41) |
Feb
(60) |
Mar
(33) |
Apr
(22) |
May
(38) |
Jun
(23) |
Jul
(86) |
Aug
(113) |
Sep
(23) |
Oct
(22) |
Nov
(18) |
Dec
(13) |
2015 |
Jan
(40) |
Feb
(12) |
Mar
(28) |
Apr
(32) |
May
(53) |
Jun
(65) |
Jul
(27) |
Aug
(6) |
Sep
(13) |
Oct
(25) |
Nov
(48) |
Dec
(19) |
2016 |
Jan
(5) |
Feb
(10) |
Mar
(23) |
Apr
(31) |
May
(19) |
Jun
(28) |
Jul
(19) |
Aug
(2) |
Sep
(9) |
Oct
(18) |
Nov
(10) |
Dec
(4) |
2017 |
Jan
(23) |
Feb
(42) |
Mar
(13) |
Apr
(5) |
May
(7) |
Jun
(26) |
Jul
(13) |
Aug
(8) |
Sep
(1) |
Oct
(3) |
Nov
(27) |
Dec
(4) |
2018 |
Jan
(9) |
Feb
(22) |
Mar
(27) |
Apr
(16) |
May
(7) |
Jun
(5) |
Jul
(7) |
Aug
(1) |
Sep
(36) |
Oct
(17) |
Nov
(1) |
Dec
(5) |
2019 |
Jan
(1) |
Feb
|
Mar
(11) |
Apr
(4) |
May
(7) |
Jun
(6) |
Jul
(9) |
Aug
(4) |
Sep
(6) |
Oct
(4) |
Nov
(5) |
Dec
(13) |
2020 |
Jan
(60) |
Feb
(57) |
Mar
(4) |
Apr
(71) |
May
(1) |
Jun
(1) |
Jul
(7) |
Aug
(11) |
Sep
(6) |
Oct
|
Nov
(2) |
Dec
|
2021 |
Jan
(42) |
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
2022 |
Jan
|
Feb
|
Mar
|
Apr
(4) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Shuah K. <sk...@li...> - 2020-11-10 20:26:11
|
seqnum_ops api is introduced to be used when a variable is used as a sequence/stat counter and doesn't guard object lifetimes. This clearly differentiates atomic_t usages that guard object lifetimes. seqnum32 variables wrap around to INT_MIN when it overflows and should not be used to guard resource lifetimes, device usage and open counts that control state changes, and pm states. atomic_t variables used for stats are atomic counters. Overflow will wrap around and reset the stats and no change with the conversion. Convert them to use seqnum_ops. Signed-off-by: Shuah Khan <sk...@li...> --- drivers/oprofile/buffer_sync.c | 9 +++++---- drivers/oprofile/event_buffer.c | 3 ++- drivers/oprofile/oprof.c | 3 ++- drivers/oprofile/oprofile_stats.c | 11 ++++++----- drivers/oprofile/oprofile_stats.h | 11 ++++++----- drivers/oprofile/oprofilefs.c | 3 ++- include/linux/oprofile.h | 3 ++- 7 files changed, 25 insertions(+), 18 deletions(-) diff --git a/drivers/oprofile/buffer_sync.c b/drivers/oprofile/buffer_sync.c index cc917865f13a..0503d467429b 100644 --- a/drivers/oprofile/buffer_sync.c +++ b/drivers/oprofile/buffer_sync.c @@ -34,6 +34,7 @@ #include <linux/sched/mm.h> #include <linux/sched/task.h> #include <linux/gfp.h> +#include <linux/seqnum_ops.h> #include "oprofile_stats.h" #include "event_buffer.h" @@ -347,7 +348,7 @@ static void add_data(struct op_entry *entry, struct mm_struct *mm) if (cookie == NO_COOKIE) offset = pc; if (cookie == INVALID_COOKIE) { - atomic_inc(&oprofile_stats.sample_lost_no_mapping); + seqnum32_inc(&oprofile_stats.sample_lost_no_mapping); offset = pc; } if (cookie != last_cookie) { @@ -391,14 +392,14 @@ add_sample(struct mm_struct *mm, struct op_sample *s, int in_kernel) /* add userspace sample */ if (!mm) { - atomic_inc(&oprofile_stats.sample_lost_no_mm); + seqnum32_inc(&oprofile_stats.sample_lost_no_mm); return 0; } cookie = lookup_dcookie(mm, s->eip, &offset); if (cookie == INVALID_COOKIE) { - atomic_inc(&oprofile_stats.sample_lost_no_mapping); + seqnum32_inc(&oprofile_stats.sample_lost_no_mapping); return 0; } @@ -556,7 +557,7 @@ void sync_buffer(int cpu) /* ignore backtraces if failed to add a sample */ if (state == sb_bt_start) { state = sb_bt_ignore; - atomic_inc(&oprofile_stats.bt_lost_no_mapping); + seqnum32_inc(&oprofile_stats.bt_lost_no_mapping); } } release_mm(mm); diff --git a/drivers/oprofile/event_buffer.c b/drivers/oprofile/event_buffer.c index 6c9edc8bbc95..6ec2f1ed8d94 100644 --- a/drivers/oprofile/event_buffer.c +++ b/drivers/oprofile/event_buffer.c @@ -19,6 +19,7 @@ #include <linux/dcookies.h> #include <linux/fs.h> #include <linux/uaccess.h> +#include <linux/seqnum_ops.h> #include "oprof.h" #include "event_buffer.h" @@ -53,7 +54,7 @@ void add_event_entry(unsigned long value) } if (buffer_pos == buffer_size) { - atomic_inc(&oprofile_stats.event_lost_overflow); + seqnum32_inc(&oprofile_stats.event_lost_overflow); return; } diff --git a/drivers/oprofile/oprof.c b/drivers/oprofile/oprof.c index ed2c3ec07024..f3183ef0f607 100644 --- a/drivers/oprofile/oprof.c +++ b/drivers/oprofile/oprof.c @@ -15,6 +15,7 @@ #include <linux/workqueue.h> #include <linux/time.h> #include <linux/mutex.h> +#include <linux/seqnum_ops.h> #include "oprof.h" #include "event_buffer.h" @@ -110,7 +111,7 @@ static void switch_worker(struct work_struct *work) if (oprofile_ops.switch_events()) return; - atomic_inc(&oprofile_stats.multiplex_counter); + seqnum32_inc(&oprofile_stats.multiplex_counter); start_switch_worker(); } diff --git a/drivers/oprofile/oprofile_stats.c b/drivers/oprofile/oprofile_stats.c index 59659cea4582..04e9b2a0d35a 100644 --- a/drivers/oprofile/oprofile_stats.c +++ b/drivers/oprofile/oprofile_stats.c @@ -11,6 +11,7 @@ #include <linux/smp.h> #include <linux/cpumask.h> #include <linux/threads.h> +#include <linux/seqnum_ops.h> #include "oprofile_stats.h" #include "cpu_buffer.h" @@ -30,11 +31,11 @@ void oprofile_reset_stats(void) cpu_buf->sample_invalid_eip = 0; } - atomic_set(&oprofile_stats.sample_lost_no_mm, 0); - atomic_set(&oprofile_stats.sample_lost_no_mapping, 0); - atomic_set(&oprofile_stats.event_lost_overflow, 0); - atomic_set(&oprofile_stats.bt_lost_no_mapping, 0); - atomic_set(&oprofile_stats.multiplex_counter, 0); + seqnum32_set(&oprofile_stats.sample_lost_no_mm, 0); + seqnum32_set(&oprofile_stats.sample_lost_no_mapping, 0); + seqnum32_set(&oprofile_stats.event_lost_overflow, 0); + seqnum32_set(&oprofile_stats.bt_lost_no_mapping, 0); + seqnum32_set(&oprofile_stats.multiplex_counter, 0); } diff --git a/drivers/oprofile/oprofile_stats.h b/drivers/oprofile/oprofile_stats.h index 1fc622bd1834..229bcbb16527 100644 --- a/drivers/oprofile/oprofile_stats.h +++ b/drivers/oprofile/oprofile_stats.h @@ -11,13 +11,14 @@ #define OPROFILE_STATS_H #include <linux/atomic.h> +#include <linux/seqnum_ops.h> struct oprofile_stat_struct { - atomic_t sample_lost_no_mm; - atomic_t sample_lost_no_mapping; - atomic_t bt_lost_no_mapping; - atomic_t event_lost_overflow; - atomic_t multiplex_counter; + struct seqnum32 sample_lost_no_mm; + struct seqnum32 sample_lost_no_mapping; + struct seqnum32 bt_lost_no_mapping; + struct seqnum32 event_lost_overflow; + struct seqnum32 multiplex_counter; }; extern struct oprofile_stat_struct oprofile_stats; diff --git a/drivers/oprofile/oprofilefs.c b/drivers/oprofile/oprofilefs.c index 0875f2f122b3..c5749b9aca11 100644 --- a/drivers/oprofile/oprofilefs.c +++ b/drivers/oprofile/oprofilefs.c @@ -17,6 +17,7 @@ #include <linux/fs_context.h> #include <linux/pagemap.h> #include <linux/uaccess.h> +#include <linux/seqnum_ops.h> #include "oprof.h" @@ -193,7 +194,7 @@ static const struct file_operations atomic_ro_fops = { int oprofilefs_create_ro_atomic(struct dentry *root, - char const *name, atomic_t *val) + char const *name, struct seqnum32 *val) { return __oprofilefs_create_file(root, name, &atomic_ro_fops, 0444, val); diff --git a/include/linux/oprofile.h b/include/linux/oprofile.h index b2a0f15f11fe..f770254a0c8a 100644 --- a/include/linux/oprofile.h +++ b/include/linux/oprofile.h @@ -19,6 +19,7 @@ #include <linux/errno.h> #include <linux/printk.h> #include <linux/atomic.h> +#include <linux/seqnum_ops.h> /* Each escaped entry is prefixed by ESCAPE_CODE * then one of the following codes, then the @@ -140,7 +141,7 @@ int oprofilefs_create_ro_ulong(struct dentry * root, /** Create a file for read-only access to an atomic_t. */ int oprofilefs_create_ro_atomic(struct dentry * root, - char const * name, atomic_t * val); + char const *name, struct seqnum32 *val); /** create a directory */ struct dentry *oprofilefs_mkdir(struct dentry *parent, char const *name); -- 2.27.0 |
From: William C. <wc...@nc...> - 2020-09-10 20:01:50
|
On 9/5/20 7:41 AM, Andrew Savchenko wrote: Thanks for the patch it has been put into the upstream oprofile git repository. -Will > When musl is used instead of glibc, oprofile build fails because it > uses glibc-specific FTW extension: FTW_ACTIONRETVAL for custom > __delete_old_previous_sample_data return codes and FTW_STOP, > FTW_CONTINUE for such return codes. Musl supports only POSIX ftw, so > build fails. > > However, this extension is not really needed by oprofile, because > FTW_SKIP_* are not used and {FTW_STOP,FTW_CONTINUE} can be handled > by standard return codes {1,0} (more precisely standard defines > {!0,0}, but in glibc FTW_STOP = 1, so I keep this value). > > Signed-off-by: Andrew Savchenko <bi...@gm...> > --- > pe_profiling/operf.cpp | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/pe_profiling/operf.cpp b/pe_profiling/operf.cpp > index 06a0ea3c..1b882b7c 100644 > --- a/pe_profiling/operf.cpp > +++ b/pe_profiling/operf.cpp > @@ -860,9 +860,9 @@ static int __delete_old_previous_sample_data(const char *fpath, > { > if (remove(fpath)) { > perror("sample data removal error"); > - return FTW_STOP; > + return 1; > } else { > - return FTW_CONTINUE; > + return 0; > } > } > > @@ -897,7 +897,7 @@ static void convert_sample_data(void) > return; > > if (!operf_options::append) { > - int flags = FTW_DEPTH | FTW_ACTIONRETVAL; > + int flags = FTW_DEPTH; > errno = 0; > if (nftw(previous_sampledir.c_str(), __delete_old_previous_sample_data, 32, flags) !=0 && > errno != ENOENT) { > -- > 2.24.0 > > Best regards, > Andrew Savchenko > > > _______________________________________________ > oprofile-list mailing list > opr...@li... > https://lists.sourceforge.net/lists/listinfo/oprofile-list |
From: William C. <wc...@nc...> - 2020-09-10 20:00:58
|
On 9/5/20 7:40 AM, Andrew Savchenko wrote: > When /bin/sh used by autoconf is not bash, e.g. dash, configure > fails because it uses bash-specific equality operator "==". > > Fix this problem by replacing "==" with POSIX "=" which is > sufficient for test where it is being used. > > Signed-off-by: Andrew Savchenko <bi...@gm...> > --- > configure.ac | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/configure.ac b/configure.ac > index 05609f6e..f5fcd17d 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -466,8 +466,8 @@ AX_COPY_IF_CHANGE(doc/xsl/catalog-1.xml, doc/xsl/catalog.xml) > > if ! test "x$enable_account_check" = "xyes"; then > : > -elif test "`getent passwd oprofile 2>/dev/null`" == "" || \ > - test "`getent group oprofile 2>/dev/null`" == ""; then > +elif test "`getent passwd oprofile 2>/dev/null`" = "" || \ > + test "`getent group oprofile 2>/dev/null`" = ""; then > if test `id -u` != "0"; then > echo "Warning: The user account 'oprofile:oprofile' does not exist on the system." > echo " To profile JITed code, this special user account must exist." > -- > 2.24.0 > > Best regards, > Andrew Savchenko Thanks for the patch. It has been put into the oprofile master branch. -Will > > > _______________________________________________ > oprofile-list mailing list > opr...@li... > https://lists.sourceforge.net/lists/listinfo/oprofile-list |
From: Michael E. <pat...@el...> - 2020-09-09 14:04:48
|
On Tue, 4 Aug 2020 18:43:16 +0100, Colin King wrote: > There is a spelling mistake in a pr_debug message. Fix it. Applied to powerpc/next. [1/1] powerpc/oprofile: fix spelling mistake "contex" -> "context" https://git.kernel.org/powerpc/c/346427e668163e85cbbe14e4d9a2ddd49df1536c cheers |
From: Martin K. P. <mar...@or...> - 2020-09-09 03:20:00
|
On Mon, 24 Aug 2020 21:55:57 -0700, Joe Perches wrote: > There are many comma separated statements in the kernel. > See:https://lore.kernel.org/lkml/alpine.DEB.2.22.394.2008201856110.2524@hadrien/ > > Convert the comma separated statements that are in if/do/while blocks > to use braces and semicolons. > > Many comma separated statements still exist but those are changes for > another day. > > [...] Applied to 5.10/scsi-queue, thanks! [01/29] coding-style.rst: Avoid comma statements (no commit info) [02/29] alpha: Avoid comma separated statements (no commit info) [03/29] ia64: Avoid comma separated statements (no commit info) [04/29] sparc: Avoid comma separated statements (no commit info) [05/29] ata: Avoid comma separated statements (no commit info) [06/29] drbd: Avoid comma separated statements (no commit info) [07/29] lp: Avoid comma separated statements (no commit info) [08/29] dma-buf: Avoid comma separated statements (no commit info) [09/29] drm/gma500: Avoid comma separated statements (no commit info) [10/29] drm/i915: Avoid comma separated statements (no commit info) [11/29] hwmon: (scmi-hwmon): Avoid comma separated statements (no commit info) [12/29] Input: MT - Avoid comma separated statements (no commit info) [13/29] bcache: Avoid comma separated statements (no commit info) [14/29] media: Avoid comma separated statements (no commit info) [15/29] mtd: Avoid comma separated statements (no commit info) [16/29] 8390: Avoid comma separated statements (no commit info) [17/29] fs_enet: Avoid comma separated statements (no commit info) [18/29] wan: sbni: Avoid comma separated statements (no commit info) [19/29] s390/tty3270: Avoid comma separated statements (no commit info) [20/29] scsi: arm: Avoid comma separated statements https://git.kernel.org/mkp/scsi/c/a08a07326510 [21/29] media: atomisp: Avoid comma separated statements (no commit info) [22/29] video: fbdev: Avoid comma separated statements (no commit info) [23/29] fuse: Avoid comma separated statements (no commit info) [24/29] reiserfs: Avoid comma separated statements (no commit info) [25/29] lib/zlib: Avoid comma separated statements (no commit info) [26/29] lib: zstd: Avoid comma separated statements (no commit info) [27/29] ipv6: fib6: Avoid comma separated statements (no commit info) [28/29] sunrpc: Avoid comma separated statements (no commit info) [29/29] tools: Avoid comma separated statements (no commit info) -- Martin K. Petersen Oracle Linux Engineering |
From: Andrew S. <bi...@gm...> - 2020-09-05 11:41:53
|
When musl is used instead of glibc, oprofile build fails because it uses glibc-specific FTW extension: FTW_ACTIONRETVAL for custom __delete_old_previous_sample_data return codes and FTW_STOP, FTW_CONTINUE for such return codes. Musl supports only POSIX ftw, so build fails. However, this extension is not really needed by oprofile, because FTW_SKIP_* are not used and {FTW_STOP,FTW_CONTINUE} can be handled by standard return codes {1,0} (more precisely standard defines {!0,0}, but in glibc FTW_STOP = 1, so I keep this value). Signed-off-by: Andrew Savchenko <bi...@gm...> --- pe_profiling/operf.cpp | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/pe_profiling/operf.cpp b/pe_profiling/operf.cpp index 06a0ea3c..1b882b7c 100644 --- a/pe_profiling/operf.cpp +++ b/pe_profiling/operf.cpp @@ -860,9 +860,9 @@ static int __delete_old_previous_sample_data(const char *fpath, { if (remove(fpath)) { perror("sample data removal error"); - return FTW_STOP; + return 1; } else { - return FTW_CONTINUE; + return 0; } } @@ -897,7 +897,7 @@ static void convert_sample_data(void) return; if (!operf_options::append) { - int flags = FTW_DEPTH | FTW_ACTIONRETVAL; + int flags = FTW_DEPTH; errno = 0; if (nftw(previous_sampledir.c_str(), __delete_old_previous_sample_data, 32, flags) !=0 && errno != ENOENT) { -- 2.24.0 Best regards, Andrew Savchenko |
From: Andrew S. <bi...@gm...> - 2020-09-05 11:40:32
|
When /bin/sh used by autoconf is not bash, e.g. dash, configure fails because it uses bash-specific equality operator "==". Fix this problem by replacing "==" with POSIX "=" which is sufficient for test where it is being used. Signed-off-by: Andrew Savchenko <bi...@gm...> --- configure.ac | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/configure.ac b/configure.ac index 05609f6e..f5fcd17d 100644 --- a/configure.ac +++ b/configure.ac @@ -466,8 +466,8 @@ AX_COPY_IF_CHANGE(doc/xsl/catalog-1.xml, doc/xsl/catalog.xml) if ! test "x$enable_account_check" = "xyes"; then : -elif test "`getent passwd oprofile 2>/dev/null`" == "" || \ - test "`getent group oprofile 2>/dev/null`" == ""; then +elif test "`getent passwd oprofile 2>/dev/null`" = "" || \ + test "`getent group oprofile 2>/dev/null`" = ""; then if test `id -u` != "0"; then echo "Warning: The user account 'oprofile:oprofile' does not exist on the system." echo " To profile JITed code, this special user account must exist." -- 2.24.0 Best regards, Andrew Savchenko |
From: Robert R. <rr...@ke...> - 2020-08-25 06:38:00
|
On 24.08.20 21:55:59, Joe Perches wrote: > Use semicolons and braces. > > Signed-off-by: Joe Perches <jo...@pe...> > --- > arch/alpha/kernel/pci_iommu.c | 8 +++++--- > arch/alpha/oprofile/op_model_ev4.c | 22 ++++++++++++++-------- > arch/alpha/oprofile/op_model_ev5.c | 8 +++++--- > 3 files changed, 24 insertions(+), 14 deletions(-) For oprofile: Acked-by: Robert Richter <rr...@ke...> |
From: Joe P. <jo...@pe...> - 2020-08-25 05:16:07
|
Use semicolons and braces. Signed-off-by: Joe Perches <jo...@pe...> --- arch/alpha/kernel/pci_iommu.c | 8 +++++--- arch/alpha/oprofile/op_model_ev4.c | 22 ++++++++++++++-------- arch/alpha/oprofile/op_model_ev5.c | 8 +++++--- 3 files changed, 24 insertions(+), 14 deletions(-) diff --git a/arch/alpha/kernel/pci_iommu.c b/arch/alpha/kernel/pci_iommu.c index 81037907268d..b8af7ad6c607 100644 --- a/arch/alpha/kernel/pci_iommu.c +++ b/arch/alpha/kernel/pci_iommu.c @@ -161,10 +161,12 @@ iommu_arena_find_pages(struct device *dev, struct pci_iommu_arena *arena, goto again; } - if (ptes[p+i]) - p = ALIGN(p + i + 1, mask + 1), i = 0; - else + if (ptes[p+i]) { + p = ALIGN(p + i + 1, mask + 1); + i = 0; + } else { i = i + 1; + } } if (i < n) { diff --git a/arch/alpha/oprofile/op_model_ev4.c b/arch/alpha/oprofile/op_model_ev4.c index 086a0d5445c5..004f80a4291f 100644 --- a/arch/alpha/oprofile/op_model_ev4.c +++ b/arch/alpha/oprofile/op_model_ev4.c @@ -46,18 +46,24 @@ ev4_reg_setup(struct op_register_config *reg, map it onto one of the possible values, and write it back. */ count = ctr[0].count; - if (count <= 4096) - count = 4096, hilo = 1; - else - count = 65536, hilo = 0; + if (count <= 4096) { + count = 4096; + hilo = 1; + } else { + count = 65536; + hilo = 0; + } ctr[0].count = count; ctl |= (ctr[0].enabled && hilo) << 3; count = ctr[1].count; - if (count <= 256) - count = 256, hilo = 1; - else - count = 4096, hilo = 0; + if (count <= 256) { + count = 256; + hilo = 1; + } else { + count = 4096; + hilo = 0; + } ctr[1].count = count; ctl |= (ctr[1].enabled && hilo); diff --git a/arch/alpha/oprofile/op_model_ev5.c b/arch/alpha/oprofile/op_model_ev5.c index c300f5ef3482..6f52244e1181 100644 --- a/arch/alpha/oprofile/op_model_ev5.c +++ b/arch/alpha/oprofile/op_model_ev5.c @@ -92,9 +92,11 @@ common_reg_setup(struct op_register_config *reg, if (!ctr[i].enabled) continue; - if (count <= 256) - count = 256, hilo = 3, max = 256; - else { + if (count <= 256) { + max = 256; + hilo = 3; + count = 256; + } else { max = (i == 2 ? 16384 : 65536); hilo = 2; if (count > max) -- 2.26.0 |
From: Joe P. <jo...@pe...> - 2020-08-25 05:15:54
|
There are many comma separated statements in the kernel. See:https://lore.kernel.org/lkml/alpine.DEB.2.22.394.2008201856110.2524@hadrien/ Convert the comma separated statements that are in if/do/while blocks to use braces and semicolons. Many comma separated statements still exist but those are changes for another day. Joe Perches (29): coding-style.rst: Avoid comma statements alpha: Avoid comma separated statements ia64: Avoid comma separated statements sparc: Avoid comma separated statements ata: Avoid comma separated statements drbd: Avoid comma separated statements lp: Avoid comma separated statements dma-buf: Avoid comma separated statements drm/gma500: Avoid comma separated statements drm/i915: Avoid comma separated statements hwmon: (scmi-hwmon): Avoid comma separated statements Input: MT - Avoid comma separated statements bcache: Avoid comma separated statements media: Avoid comma separated statements mtd: Avoid comma separated statements 8390: Avoid comma separated statements fs_enet: Avoid comma separated statements wan: sbni: Avoid comma separated statements s390/tty3270: Avoid comma separated statements scai/arm: Avoid comma separated statements media: atomisp: Avoid comma separated statements video: fbdev: Avoid comma separated statements fuse: Avoid comma separated statements reiserfs: Avoid comma separated statements lib/zlib: Avoid comma separated statements lib: zstd: Avoid comma separated statements ipv6: fib6: Avoid comma separated statements sunrpc: Avoid comma separated statements tools: Avoid comma separated statements Documentation/process/coding-style.rst | 17 + arch/alpha/kernel/pci_iommu.c | 8 +- arch/alpha/oprofile/op_model_ev4.c | 22 +- arch/alpha/oprofile/op_model_ev5.c | 8 +- arch/ia64/kernel/smpboot.c | 7 +- arch/sparc/kernel/smp_64.c | 7 +- drivers/ata/pata_icside.c | 21 +- drivers/block/drbd/drbd_receiver.c | 6 +- drivers/char/lp.c | 6 +- drivers/dma-buf/st-dma-fence.c | 7 +- drivers/gpu/drm/gma500/mdfld_intel_display.c | 44 ++- drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 8 +- drivers/gpu/drm/i915/gt/intel_gt_requests.c | 6 +- .../gpu/drm/i915/gt/selftest_workarounds.c | 6 +- drivers/gpu/drm/i915/intel_runtime_pm.c | 6 +- drivers/hwmon/scmi-hwmon.c | 6 +- drivers/input/input-mt.c | 11 +- drivers/md/bcache/bset.c | 12 +- drivers/md/bcache/sysfs.c | 6 +- drivers/media/i2c/msp3400-kthreads.c | 12 +- drivers/media/pci/bt8xx/bttv-cards.c | 6 +- drivers/media/pci/saa7134/saa7134-video.c | 7 +- drivers/mtd/devices/lart.c | 10 +- drivers/net/ethernet/8390/axnet_cs.c | 19 +- drivers/net/ethernet/8390/lib8390.c | 14 +- drivers/net/ethernet/8390/pcnet_cs.c | 6 +- .../ethernet/freescale/fs_enet/fs_enet-main.c | 11 +- drivers/net/wan/sbni.c | 101 +++--- drivers/s390/char/tty3270.c | 6 +- drivers/scsi/arm/cumana_2.c | 19 +- drivers/scsi/arm/eesox.c | 9 +- drivers/scsi/arm/powertec.c | 9 +- .../media/atomisp/pci/atomisp_subdev.c | 6 +- drivers/video/fbdev/tgafb.c | 12 +- fs/fuse/dir.c | 24 +- fs/reiserfs/fix_node.c | 36 ++- lib/zlib_deflate/deftree.c | 49 ++- lib/zstd/compress.c | 120 ++++--- lib/zstd/fse_compress.c | 24 +- lib/zstd/huf_compress.c | 6 +- net/ipv6/ip6_fib.c | 12 +- net/sunrpc/sysctl.c | 6 +- tools/lib/subcmd/help.c | 10 +- tools/power/cpupower/utils/cpufreq-set.c | 14 +- tools/testing/selftests/vm/gup_benchmark.c | 18 +- tools/testing/selftests/vm/userfaultfd.c | 296 +++++++++++------- 46 files changed, 694 insertions(+), 382 deletions(-) -- 2.26.0 |
From: Thomas B. <tsb...@al...> - 2020-08-21 14:07:44
|
On Fri, Aug 21, 2020 at 04:23:28AM -0500, Gustavo A. R. Silva wrote: > > > On 8/21/20 03:46, He Zhe wrote: > > > > > > On 8/21/20 3:48 PM, Thomas Bogendoerfer wrote: > >> On Thu, Aug 20, 2020 at 08:54:40PM +0800, zh...@wi... wrote: > >>> From: He Zhe <zh...@wi...> > >>> > >>> We want neither > >>> " > >>> include/linux/compiler_attributes.h:201:41: warning: statement will never > >>> be executed [-Wswitch-unreachable] > >>> 201 | # define fallthrough __attribute__((__fallthrough__)) > >>> | ^~~~~~~~~~~~~ > >>> " > >>> nor > >>> " > >>> include/linux/compiler_attributes.h:201:41: warning: attribute > >>> 'fallthrough' not preceding a case label or default label > >>> 201 | # define fallthrough __attribute__((__fallthrough__)) > >>> | ^~~~~~~~~~~~~ > >>> " > >>> > >>> It's not worth adding one more macro. Let's simply place the fallthrough > >>> in between the expansions. > >>> > >>> Signed-off-by: He Zhe <zh...@wi...> > >> there is already another patch for the problem, which I've applied > >> to mips-fixes. > > > > You mean the below one? > > https://git.kernel.org/pub/scm/linux/kernel/git/mips/linux.git/commit/?h=mips-fixes&id=5900acb374fe2f4f42bbcb2c84db64f582d917a1 > > > > That patch handles the first warning in my commit log but does not handle the > > second one which is introduced since gcc v10.1.0 commit 6c80b1b56dec > > ("Make more bad uses of fallthrough attribute into pedwarns."). > > > > This is true. > > Thomas, please apply this patch instead of mine. Also, consider adding > the Fixes tag and CC stable due to the non-executable code error, and > my Reviewed-by: > > Fixes: c9b029903466 ("MIPS: Use fallthrough for arch/mips") > Cc: st...@vg... > Reviewed-by: Gustavo A. R. Silva <gus...@ke...> done. Thomas. -- Crap can work. Given enough thrust pigs will fly, but it's not necessarily a good idea. [ RFC1925, 2.3 ] |
From: Gustavo A. R. S. <gu...@em...> - 2020-08-21 09:39:14
|
On 8/21/20 03:46, He Zhe wrote: > > > On 8/21/20 3:48 PM, Thomas Bogendoerfer wrote: >> On Thu, Aug 20, 2020 at 08:54:40PM +0800, zh...@wi... wrote: >>> From: He Zhe <zh...@wi...> >>> >>> We want neither >>> " >>> include/linux/compiler_attributes.h:201:41: warning: statement will never >>> be executed [-Wswitch-unreachable] >>> 201 | # define fallthrough __attribute__((__fallthrough__)) >>> | ^~~~~~~~~~~~~ >>> " >>> nor >>> " >>> include/linux/compiler_attributes.h:201:41: warning: attribute >>> 'fallthrough' not preceding a case label or default label >>> 201 | # define fallthrough __attribute__((__fallthrough__)) >>> | ^~~~~~~~~~~~~ >>> " >>> >>> It's not worth adding one more macro. Let's simply place the fallthrough >>> in between the expansions. >>> >>> Signed-off-by: He Zhe <zh...@wi...> >> there is already another patch for the problem, which I've applied >> to mips-fixes. > > You mean the below one? > https://git.kernel.org/pub/scm/linux/kernel/git/mips/linux.git/commit/?h=mips-fixes&id=5900acb374fe2f4f42bbcb2c84db64f582d917a1 > > That patch handles the first warning in my commit log but does not handle the > second one which is introduced since gcc v10.1.0 commit 6c80b1b56dec > ("Make more bad uses of fallthrough attribute into pedwarns."). > This is true. Thomas, please apply this patch instead of mine. Also, consider adding the Fixes tag and CC stable due to the non-executable code error, and my Reviewed-by: Fixes: c9b029903466 ("MIPS: Use fallthrough for arch/mips") Cc: st...@vg... Reviewed-by: Gustavo A. R. Silva <gus...@ke...> Thanks -- Gustavo |
From: He Z. <zh...@wi...> - 2020-08-21 09:20:24
|
On 8/21/20 3:48 PM, Thomas Bogendoerfer wrote: > On Thu, Aug 20, 2020 at 08:54:40PM +0800, zh...@wi... wrote: >> From: He Zhe <zh...@wi...> >> >> We want neither >> " >> include/linux/compiler_attributes.h:201:41: warning: statement will never >> be executed [-Wswitch-unreachable] >> 201 | # define fallthrough __attribute__((__fallthrough__)) >> | ^~~~~~~~~~~~~ >> " >> nor >> " >> include/linux/compiler_attributes.h:201:41: warning: attribute >> 'fallthrough' not preceding a case label or default label >> 201 | # define fallthrough __attribute__((__fallthrough__)) >> | ^~~~~~~~~~~~~ >> " >> >> It's not worth adding one more macro. Let's simply place the fallthrough >> in between the expansions. >> >> Signed-off-by: He Zhe <zh...@wi...> > there is already another patch for the problem, which I've applied > to mips-fixes. You mean the below one? https://git.kernel.org/pub/scm/linux/kernel/git/mips/linux.git/commit/?h=mips-fixes&id=5900acb374fe2f4f42bbcb2c84db64f582d917a1 That patch handles the first warning in my commit log but does not handle the second one which is introduced since gcc v10.1.0 commit 6c80b1b56dec ("Make more bad uses of fallthrough attribute into pedwarns."). Zhe > > Thomas. > |
From: Thomas B. <tsb...@al...> - 2020-08-21 08:04:06
|
On Tue, Aug 18, 2020 at 11:58:13PM -0500, Gustavo A. R. Silva wrote: > The fallthrough pseudo-keyword is being wrongly used and is causing > the non-executable code error below: > > arch/mips/oprofile/op_model_mipsxx.c: In function ‘mipsxx_perfcount_handler’: > ./include/linux/compiler_attributes.h:214:41: warning: statement will never be executed [-Wswitch-unreachable] > # define fallthrough __attribute__((__fallthrough__)) > ^ > arch/mips/oprofile/op_model_mipsxx.c:248:2: note: in expansion of macro ‘fallthrough’ > fallthrough; \ > ^~~~~~~~~~~ > arch/mips/oprofile/op_model_mipsxx.c:258:2: note: in expansion of macro ‘HANDLE_COUNTER’ > HANDLE_COUNTER(3) > ^~~~~~~~~~~~~~ > > Fix this by placing the fallthrough macro at the proper place. > > Fixes: c9b029903466 ("MIPS: Use fallthrough for arch/mips") > Cc: st...@vg... > Signed-off-by: Gustavo A. R. Silva <gus...@ke...> > --- > arch/mips/oprofile/op_model_mipsxx.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) applied to mips-fixes. Thomas. -- Crap can work. Given enough thrust pigs will fly, but it's not necessarily a good idea. [ RFC1925, 2.3 ] |
From: Thomas B. <tsb...@al...> - 2020-08-21 08:03:59
|
On Thu, Aug 20, 2020 at 08:54:40PM +0800, zh...@wi... wrote: > From: He Zhe <zh...@wi...> > > We want neither > " > include/linux/compiler_attributes.h:201:41: warning: statement will never > be executed [-Wswitch-unreachable] > 201 | # define fallthrough __attribute__((__fallthrough__)) > | ^~~~~~~~~~~~~ > " > nor > " > include/linux/compiler_attributes.h:201:41: warning: attribute > 'fallthrough' not preceding a case label or default label > 201 | # define fallthrough __attribute__((__fallthrough__)) > | ^~~~~~~~~~~~~ > " > > It's not worth adding one more macro. Let's simply place the fallthrough > in between the expansions. > > Signed-off-by: He Zhe <zh...@wi...> there is already another patch for the problem, which I've applied to mips-fixes. Thomas. -- Crap can work. Given enough thrust pigs will fly, but it's not necessarily a good idea. [ RFC1925, 2.3 ] |
From: <zh...@wi...> - 2020-08-20 15:00:10
|
From: He Zhe <zh...@wi...> We want neither " include/linux/compiler_attributes.h:201:41: warning: statement will never be executed [-Wswitch-unreachable] 201 | # define fallthrough __attribute__((__fallthrough__)) | ^~~~~~~~~~~~~ " nor " include/linux/compiler_attributes.h:201:41: warning: attribute 'fallthrough' not preceding a case label or default label 201 | # define fallthrough __attribute__((__fallthrough__)) | ^~~~~~~~~~~~~ " It's not worth adding one more macro. Let's simply place the fallthrough in between the expansions. Signed-off-by: He Zhe <zh...@wi...> --- arch/mips/oprofile/op_model_mipsxx.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/arch/mips/oprofile/op_model_mipsxx.c b/arch/mips/oprofile/op_model_mipsxx.c index 1493c49ca47a..55d7b7fd18b6 100644 --- a/arch/mips/oprofile/op_model_mipsxx.c +++ b/arch/mips/oprofile/op_model_mipsxx.c @@ -245,7 +245,6 @@ static int mipsxx_perfcount_handler(void) switch (counters) { #define HANDLE_COUNTER(n) \ - fallthrough; \ case n + 1: \ control = r_c0_perfctrl ## n(); \ counter = r_c0_perfcntr ## n(); \ @@ -256,8 +255,11 @@ static int mipsxx_perfcount_handler(void) handled = IRQ_HANDLED; \ } HANDLE_COUNTER(3) + fallthrough; HANDLE_COUNTER(2) + fallthrough; HANDLE_COUNTER(1) + fallthrough; HANDLE_COUNTER(0) } -- 2.17.1 |
From: Gustavo A. R. S. <gus...@ke...> - 2020-08-19 05:10:42
|
The fallthrough pseudo-keyword is being wrongly used and is causing the non-executable code error below: arch/mips/oprofile/op_model_mipsxx.c: In function ‘mipsxx_perfcount_handler’: ./include/linux/compiler_attributes.h:214:41: warning: statement will never be executed [-Wswitch-unreachable] # define fallthrough __attribute__((__fallthrough__)) ^ arch/mips/oprofile/op_model_mipsxx.c:248:2: note: in expansion of macro ‘fallthrough’ fallthrough; \ ^~~~~~~~~~~ arch/mips/oprofile/op_model_mipsxx.c:258:2: note: in expansion of macro ‘HANDLE_COUNTER’ HANDLE_COUNTER(3) ^~~~~~~~~~~~~~ Fix this by placing the fallthrough macro at the proper place. Fixes: c9b029903466 ("MIPS: Use fallthrough for arch/mips") Cc: st...@vg... Signed-off-by: Gustavo A. R. Silva <gus...@ke...> --- arch/mips/oprofile/op_model_mipsxx.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/mips/oprofile/op_model_mipsxx.c b/arch/mips/oprofile/op_model_mipsxx.c index 1493c49ca47a..f200b97bdef7 100644 --- a/arch/mips/oprofile/op_model_mipsxx.c +++ b/arch/mips/oprofile/op_model_mipsxx.c @@ -245,7 +245,6 @@ static int mipsxx_perfcount_handler(void) switch (counters) { #define HANDLE_COUNTER(n) \ - fallthrough; \ case n + 1: \ control = r_c0_perfctrl ## n(); \ counter = r_c0_perfcntr ## n(); \ @@ -254,7 +253,8 @@ static int mipsxx_perfcount_handler(void) oprofile_add_sample(get_irq_regs(), n); \ w_c0_perfcntr ## n(reg.counter[n]); \ handled = IRQ_HANDLED; \ - } + } \ + fallthrough; HANDLE_COUNTER(3) HANDLE_COUNTER(2) HANDLE_COUNTER(1) -- 2.27.0 |
From: Colin K. <col...@ca...> - 2020-08-04 18:00:47
|
From: Colin Ian King <col...@ca...> There is a spelling mistake in a pr_debug message. Fix it. Signed-off-by: Colin Ian King <col...@ca...> --- arch/powerpc/oprofile/cell/spu_task_sync.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/powerpc/oprofile/cell/spu_task_sync.c b/arch/powerpc/oprofile/cell/spu_task_sync.c index df59d0bb121f..489f993100d5 100644 --- a/arch/powerpc/oprofile/cell/spu_task_sync.c +++ b/arch/powerpc/oprofile/cell/spu_task_sync.c @@ -572,7 +572,7 @@ void spu_sync_buffer(int spu_num, unsigned int *samples, * samples are recorded. * No big deal -- so we just drop a few samples. */ - pr_debug("SPU_PROF: No cached SPU contex " + pr_debug("SPU_PROF: No cached SPU context " "for SPU #%d. Dropping samples.\n", spu_num); goto out; } -- 2.27.0 |
From: John L. <joh...@ho...> - 2020-07-31 15:32:39
|
On 07/28/20 17:00, William Cohen wrote: > > One though is how exactly are you starting doing the profiling? Like the the following: > > operf <command_to_profile> > > Or attaching to a running process? > > operf --pid <pid> > > Or doing systemwide monitoring with --system-wide? Thanks William, my operf command is operf --vmlinux /mnt/bullbild/linux-5.7.4-bullarch/vmlinux --session-dir=/tmp/oprof_session.200724_120854 --callgraph --separate-cpu --system-wide so yes, system-wide. > > You might check to see if the linux perf command has a similar problem with the quick spawn and death of processes. > operf is using the same mechanism in the kernel to collect performance event samples. There are some cases where the scanning of /proc can get behind the rapid creation and death of processes. It would be useful to know if the problem lies with oprofile or is also seen in perf. I will try with perf some time but have never used that before (did not know about it) so may be a little while getting to it. Cheers, John |
From: William C. <wc...@re...> - 2020-07-28 21:16:31
|
On 7/24/20 11:47 AM, J Lumby wrote: > On 7/21/20 5:47 PM, J Lumby wrote: >> >> On 7/21/20 9:48 AM, William Cohen wrote: >>> >>> Could you give that new release of oprofile a try? >>> >>> -Will >> >> >> I saw 1.4.0 available almost immediately after I posted that. I've now tried the same run on 1.4.0 (compiled on the target machine just to be sure it compiles with the same bfd headers and libs) and there are mixed results. >> >> It is still losing 80% of all userspace events : see below; >> >> > I turned on --verbose="debug,convert" and from that, discovered the explanation for the very high loss. > > My workload was forking a large number of processes in sequence, each of which did a certain amount of work (typically around 5 seconds-worth on a single CPU) and then exited. I guess operf's handling of the mapping events takes something of the same order of time to understand each process, by which time it has gone. One though is how exactly are you starting doing the profiling? Like the the following: operf <command_to_profile> Or attaching to a running process? operf --pid <pid> Or doing systemwide monitoring with --system-wide? You might check to see if the linux perf command has a similar problem with the quick spawn and death of processes. operf is using the same mechanism in the kernel to collect performance event samples. There are some cases where the scanning of /proc can get behind the rapid creation and death of processes. It would be useful to know if the problem lies with oprofile or is also seen in perf. -Will > > I changed the workload to do all the work in a single continuous process and now it works well : > > Profiling started at Fri Jul 24 11:15:41 2020 > Profiling stopped at Fri Jul 24 11:17:07 2020 > > -- OProfile/operf Statistics -- > Nr. non-backtrace samples: 12791 > Nr. kernel samples: 2248 > Nr. user space samples: 10543 > Nr. samples lost due to sample address not in expected range for domain: 0 > Nr. lost kernel samples: 0 > Nr. samples lost due to sample file open failure: 0 > Nr. samples lost due to no permanent mapping: 34 > Nr. user context kernel samples lost due to no app info available: 89 > Nr. user samples lost due to no app info available: 0 > Nr. backtraces skipped due to no file mapping: 34 > Nr. hypervisor samples dropped due to address out-of-range: 0 > Nr. samples lost reported by perf_events kernel: 0 > |
From: J L. <joh...@ho...> - 2020-07-24 15:47:36
|
On 7/21/20 5:47 PM, J Lumby wrote: > > On 7/21/20 9:48 AM, William Cohen wrote: >> >> Could you give that new release of oprofile a try? >> >> -Will > > > I saw 1.4.0 available almost immediately after I posted that. I've now > tried the same run on 1.4.0 (compiled on the target machine just to be > sure it compiles with the same bfd headers and libs) and there are > mixed results. > > It is still losing 80% of all userspace events : see below; > > I turned on --verbose="debug,convert" and from that, discovered the explanation for the very high loss. My workload was forking a large number of processes in sequence, each of which did a certain amount of work (typically around 5 seconds-worth on a single CPU) and then exited. I guess operf's handling of the mapping events takes something of the same order of time to understand each process, by which time it has gone. I changed the workload to do all the work in a single continuous process and now it works well : Profiling started at Fri Jul 24 11:15:41 2020 Profiling stopped at Fri Jul 24 11:17:07 2020 -- OProfile/operf Statistics -- Nr. non-backtrace samples: 12791 Nr. kernel samples: 2248 Nr. user space samples: 10543 Nr. samples lost due to sample address not in expected range for domain: 0 Nr. lost kernel samples: 0 Nr. samples lost due to sample file open failure: 0 Nr. samples lost due to no permanent mapping: 34 Nr. user context kernel samples lost due to no app info available: 89 Nr. user samples lost due to no app info available: 0 Nr. backtraces skipped due to no file mapping: 34 Nr. hypervisor samples dropped due to address out-of-range: 0 Nr. samples lost reported by perf_events kernel: 0 |
From: J L. <joh...@ho...> - 2020-07-21 21:47:23
|
On 7/21/20 9:48 AM, William Cohen wrote: > On 7/20/20 9:03 PM, J Lumby wrote: >> Oprofiling an intensive postgresql workload running on a Lenovo P52 and lniux kernel 5.7.4, I see very high numbers of both of these : approximately two-thirds of all user-space samples are being lost. see operf.log below >> >> > Hi, > > Which version of oprofile was being used? I just did a release of oprofile-1.4.0 it has commit [a3742f]: That run was on 1.3.0 > > Use the mmap offset to correctly compute the IP location in a file > > Newer versions of binutils are now now splitting the file into > multiple mmap loads. The assumption that the mmap for the executable > code in the file starts at the beginning of the file (that the file > offset is always zero) is no longer true. The computation to convert > the IP address into an offset needs to also use the offset. > > I wonder if maybe that a number of the samples might be discarded because they are not being mapped to reasonable locations in executables. > > Could you give that new release of oprofile a try? > > -Will I saw 1.4.0 available almost immediately after I posted that. I've now tried the same run on 1.4.0 (compiled on the target machine just to be sure it compiles with the same bfd headers and libs) and there are mixed results. It is still losing 80% of all userspace events : see below; but also the reports now show a completely different and much more "what-I-would-expect" list of tickcounts by function, so maybe I can make do with this release. But this improvement makes me wonder if maybe the fix is in the right direction but not quite there yet. Is that possible? Would switching on the -V "all' debugging help narrow down what is happening? Also if you can point me to the code changes I can take a look and maybe spot something. Cheers, John ___________________________________________________________ on 1.4.0 operf --vmlinux /mnt/bullbild/linux-5.7.4-bullarch/vmlinux --session-dir /tmp/oprof_session.200721-173111 --events cpu_clk_unhalted:50000000:thread:1:1 --callgraph --separate-cpu --system-wide Profiling started at Tue Jul 21 17:31:11 2020 Profiling stopped at Tue Jul 21 17:33:30 2020 -- OProfile/operf Statistics -- Nr. non-backtrace samples: 12423 Nr. kernel samples: 2170 Nr. user space samples: 10253 Nr. samples lost due to sample address not in expected range for domain: 0 Nr. lost kernel samples: 0 Nr. samples lost due to sample file open failure: 0 Nr. samples lost due to no permanent mapping: 8031 Nr. user context kernel samples lost due to no app info available: 0 Nr. user samples lost due to no app info available: 0 Nr. backtraces skipped due to no file mapping: 8029 Nr. hypervisor samples dropped due to address out-of-range: 0 Nr. samples lost reported by perf_events kernel: 0 |
From: William C. <wc...@re...> - 2020-07-21 13:49:01
|
On 7/20/20 9:03 PM, J Lumby wrote: > Oprofiling an intensive postgresql workload running on a Lenovo P52 and lniux kernel 5.7.4, I see very high numbers of both of these : approximately two-thirds of all user-space samples are being lost. see operf.log below > > > The operf command I've used is > > operf --vmlinux /mnt/bullbild/linux-5.7.4-bullarch/vmlinux --session-dir /tmp/oprof_session.200720-195024 --events cpu_clk_unhalted:30000045:thread:1:1 --callgraph --separate-cpu --system-wide > > > and it works but tells me > > WARNING: Lost samples detected! See /tmp/oprof_session.200720-195024/samples/operf.log for details. > > > Lowering the sampling rate as suggested does not help : I tried with a count of 99999999 and same high lost samples. > > > I assume oprofile somehow is unable to map the instruction pointer of the event to any process? How does it do this? Is there any setting or control or hint that I can set to help it? or , failing that, is there any way I can ask opreport to give me the results as raw instruction addresses? > > > Help! Hi, Which version of oprofile was being used? I just did a release of oprofile-1.4.0 it has commit [a3742f]: Use the mmap offset to correctly compute the IP location in a file Newer versions of binutils are now now splitting the file into multiple mmap loads. The assumption that the mmap for the executable code in the file starts at the beginning of the file (that the file offset is always zero) is no longer true. The computation to convert the IP address into an offset needs to also use the offset. I wonder if maybe that a number of the samples might be discarded because they are not being mapped to reasonable locations in executables. Could you give that new release of oprofile a try? -Will > > > Cheers, John Lumby > > ___________________________________________________________ > > Profiling started at Mon Jul 20 19:50:24 2020 > Profiling stopped at Mon Jul 20 19:51:25 2020 > > -- OProfile/operf Statistics -- > Nr. non-backtrace samples: 9435 > Nr. kernel samples: 1924 > Nr. user space samples: 7511 > Nr. samples lost due to sample address not in expected range for domain: 0 > Nr. lost kernel samples: 0 > Nr. samples lost due to sample file open failure: 0 > Nr. samples lost due to no permanent mapping: 4967 > Nr. user context kernel samples lost due to no app info available: 0 > Nr. user samples lost due to no app info available: 0 > Nr. backtraces skipped due to no file mapping: 4967 > Nr. hypervisor samples dropped due to address out-of-range: 0 > Nr. samples lost reported by perf_events kernel: 0 > > > > _______________________________________________ > oprofile-list mailing list > opr...@li... > https://lists.sourceforge.net/lists/listinfo/oprofile-list |
From: J L. <joh...@ho...> - 2020-07-21 01:03:01
|
Oprofiling an intensive postgresql workload running on a Lenovo P52 and lniux kernel 5.7.4, I see very high numbers of both of these : approximately two-thirds of all user-space samples are being lost. see operf.log below The operf command I've used is operf --vmlinux /mnt/bullbild/linux-5.7.4-bullarch/vmlinux --session-dir /tmp/oprof_session.200720-195024 --events cpu_clk_unhalted:30000045:thread:1:1 --callgraph --separate-cpu --system-wide and it works but tells me WARNING: Lost samples detected! See /tmp/oprof_session.200720-195024/samples/operf.log for details. Lowering the sampling rate as suggested does not help : I tried with a count of 99999999 and same high lost samples. I assume oprofile somehow is unable to map the instruction pointer of the event to any process? How does it do this? Is there any setting or control or hint that I can set to help it? or , failing that, is there any way I can ask opreport to give me the results as raw instruction addresses? Help! Cheers, John Lumby ___________________________________________________________ Profiling started at Mon Jul 20 19:50:24 2020 Profiling stopped at Mon Jul 20 19:51:25 2020 -- OProfile/operf Statistics -- Nr. non-backtrace samples: 9435 Nr. kernel samples: 1924 Nr. user space samples: 7511 Nr. samples lost due to sample address not in expected range for domain: 0 Nr. lost kernel samples: 0 Nr. samples lost due to sample file open failure: 0 Nr. samples lost due to no permanent mapping: 4967 Nr. user context kernel samples lost due to no app info available: 0 Nr. user samples lost due to no app info available: 0 Nr. backtraces skipped due to no file mapping: 4967 Nr. hypervisor samples dropped due to address out-of-range: 0 Nr. samples lost reported by perf_events kernel: 0 |
From: Alexander A. K. <gra...@al...> - 2020-07-08 10:32:56
|
Rationale: Reduces attack surface on kernel devs opening the links for MITM as HTTPS traffic is much harder to manipulate. Deterministic algorithm: For each file: If not .svg: For each line: If doesn't contain `\bxmlns\b`: For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`: If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`: If both the HTTP and HTTPS versions return 200 OK and serve the same content: Replace HTTP with HTTPS. Signed-off-by: Alexander A. Klimov <gra...@al...> --- Continuing my work started at 93431e0607e5. See also: git log --oneline '--author=Alexander A. Klimov <gra...@al...>' v5.7..master (Actually letting a shell for loop submit all this stuff for me.) If there are any URLs to be removed completely or at least not HTTPSified: Just clearly say so and I'll *undo my change*. See also: https://lkml.org/lkml/2020/6/27/64 If there are any valid, but yet not changed URLs: See: https://lkml.org/lkml/2020/6/26/837 If you apply the patch, please let me know. arch/x86/oprofile/nmi_int.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/oprofile/nmi_int.c b/arch/x86/oprofile/nmi_int.c index a7a7677265b6..0db06895cf90 100644 --- a/arch/x86/oprofile/nmi_int.c +++ b/arch/x86/oprofile/nmi_int.c @@ -621,7 +621,7 @@ static int __init ppro_init(char **cpu_type) * and model can be found in the Intel Software Developer's * Manuals (SDM): * - * http://www.intel.com/products/processor/manuals/ + * https://www.intel.com/products/processor/manuals/ * * As of May 2010 the documentation for this was in the: * "Intel 64 and IA-32 Architectures Software Developer's -- 2.27.0 |