Re: [PATCH 2/3] tracing: Use pr_crit() instead of long fancy messages

On Wed, 31 Mar 2021 11:31:03 +0200 Geert Uytterhoeven wrote: > This reduces kernel size by ca. 0.5 KiB. If you are worried about size, disable tracing and it will go away entirely. 0.5KiB is a drop in the bucket compared to what tracing adds in size overhead. Sorry, but NAK. This has been

Re: [PATCH v8 6/7] iommu/vt-d: Add trace events for device dma map/unmap

Pan > Cc: Kevin Tian > Signed-off-by: Mika Westerberg > Signed-off-by: Lu Baolu > Reviewed-by: Steven Rostedt (VMware) > --- > drivers/iommu/Makefile | 1 + > drivers/iommu/intel-trace.c| 14 + > include/trace/events/intel_iommu.h | 84

Re: [PATCH v5 09/10] iommu/vt-d: Add trace events for device dma map/unmap

0 insertions(+) > create mode 100644 drivers/iommu/intel-trace.c > create mode 100644 include/trace/events/intel_iommu.h This patch looks fine, but I don't see the use cases for anything but trace_bounce_map_single() and trace_bounce_unmap_single() used. Other than that. Reviewed-by:

Re: [PATCH v4 7/9] iommu/vt-d: Add trace events for domain map/unmap

On Mon, 3 Jun 2019 09:16:18 +0800 Lu Baolu wrote: > +TRACE_EVENT(bounce_unmap_single, > + TP_PROTO(struct device *dev, dma_addr_t dev_addr, size_t size), > + > + TP_ARGS(dev, dev_addr, size), > + > + TP_STRUCT__entry( > + __string(dev_name, dev_name(dev)) > +

Re: [patch V2 23/29] tracing: Simplify stack trace retrieval

On Thu, 18 Apr 2019 10:41:42 +0200 Thomas Gleixner wrote: > Replace the indirection through struct stack_trace by using the storage > array based interfaces. > > Signed-off-by: Thomas Gleixner > Cc: Steven Rostedt Reviewed-by: Steven Rostedt (VMw

Re: [patch V2 24/29] tracing: Remove the last struct stack_trace usage

On Thu, 18 Apr 2019 10:41:43 +0200 Thomas Gleixner wrote: > Simplify the stack retrieval code by using the storage array based > interface. > > Signed-off-by: Thomas Gleixner Reviewed-by: Steven Rostedt (VMware) -- Steve ___ iommu

Re: [patch V2 22/29] tracing: Make ftrace_trace_userstack() static and conditional

On Thu, 18 Apr 2019 10:41:41 +0200 Thomas Gleixner wrote: > It's only used in trace.c and there is absolutely no point in compiling it > in when user space stack traces are not supported. > > Signed-off-by: Thomas Gleixner > Cc: Steven Rostedt Funny, these were moved out to g

Re: [patch V2 01/29] tracing: Cleanup stack trace code

On Fri, 19 Apr 2019 00:44:17 +0200 (CEST) Thomas Gleixner wrote: > On Thu, 18 Apr 2019, Steven Rostedt wrote: > > On Thu, 18 Apr 2019 10:41:20 +0200 > > Thomas Gleixner wrote: > > > > > @@ -412,23 +404,20 @@ stack_trace_sysctl(struct ctl_table *tab > >

Re: [patch V2 01/29] tracing: Cleanup stack trace code

o begin with. I think I copied something else that couldn't do it this way for some reason and didn't put any brain power behind the copy. :-/ But that was back in 2008 so I blame it on being "young and stupid" ;-) Other then the above nit and removing the unneeded +1 in max_entri

Re: [patch V2 01/29] tracing: Cleanup stack trace code

On Thu, 18 Apr 2019 17:24:43 -0400 Steven Rostedt wrote: > I believe it was for historical leftovers (there was a time it was > required), and left there for "paranoid" sake. But let me apply the > patch and see if it is really needed. I removed the +1 on the

Re: [patch V2 01/29] tracing: Cleanup stack trace code

On Thu, 18 Apr 2019 23:14:45 +0200 (CEST) Thomas Gleixner wrote: > On Thu, 18 Apr 2019, Josh Poimboeuf wrote: > > > On Thu, Apr 18, 2019 at 10:41:20AM +0200, Thomas Gleixner wrote: > > > - Remove the extra array member of stack_dump_trace[]. It's not required > > > as > > > the stack

Re: [patch V2 20/29] tracing: Simplify stacktrace retrieval in histograms

On Thu, 18 Apr 2019 14:58:55 -0500 Tom Zanussi wrote: > > Tom, > > > > Can you review this too? > > Looks good to me too! > > Acked-by: Tom Zanussi > Would you be OK to upgrade this to a Reviewed-by tag? Thanks! -- Steve ___ iommu mailing

Re: [patch V2 21/29] tracing: Use percpu stack trace buffer more intelligently

On Thu, 18 Apr 2019 17:43:59 +0200 (CEST) Thomas Gleixner wrote: > On Thu, 18 Apr 2019, Steven Rostedt wrote: > > On Thu, 18 Apr 2019 10:41:40 +0200 > > Thomas Gleixner wrote: > > > -static DEFINE_PER_CPU(struct ftrace_stack, ftrace_stack); > > > +/*

Re: [patch V2 21/29] tracing: Use percpu stack trace buffer more intelligently

e cpu buffer > for stack retrieval and avoids the fixed length allocation along with the > conditional execution pathes. > > Signed-off-by: Thomas Gleixner > Cc: Steven Rostedt > --- > kernel/trace/trace.c | 77 > +-- &

Re: [patch V2 20/29] tracing: Simplify stacktrace retrieval in histograms

[ Added Tom Zanussi ] On Thu, 18 Apr 2019 10:41:39 +0200 Thomas Gleixner wrote: > The indirection through struct stack_trace is not necessary at all. Use the > storage array based interface. > > Signed-off-by: Thomas Gleixner > Cc: Steven Rostedt Looks fine to me Acked-by:

Re: [patch V2 14/29] dm bufio: Simplify stack trace retrieval

On Thu, 18 Apr 2019 14:11:44 +0200 Alexander Potapenko wrote: > On Thu, Apr 18, 2019 at 1:54 PM Thomas Gleixner wrote: > > > > On Thu, 18 Apr 2019, Alexander Potapenko wrote: > > > On Thu, Apr 18, 2019 at 11:06 AM Thomas Gleixner > > > wrote: > > > > -

Re: [RFC patch 28/41] dma/debug: Simplify stracktrace retrieval

On Thu, 11 Apr 2019 19:21:30 +0200 Christoph Hellwig wrote: > > Bah. People complain about overly broad cc-lists and the context is on > > lkml. But sure, I just bounced it to you. > > People should stop complaining about that. Deleting a mail is a single > keystroke. Finding all the

Re: [RFC patch 28/41] dma/debug: Simplify stracktrace retrieval

On Wed, 10 Apr 2019 22:02:01 -0500 Josh Poimboeuf wrote: > > #ifdef CONFIG_STACKTRACE > > - struct stack_trace stacktrace; > > - unsigned longst_entries[DMA_DEBUG_STACKTRACE_ENTRIES]; > > + unsigned intst_len; > > + unsigned long

Re: [RFC patch 28/41] dma/debug: Simplify stracktrace retrieval

On Wed, 10 Apr 2019 14:08:19 +0200 (CEST) Thomas Gleixner wrote: > On Wed, 10 Apr 2019, Christoph Hellwig wrote: > > > > Please always send the whole series out to everyone on the To and Cc > > list, otherwise patch series are not reviewable. > > Bah. People complain about overly broad

[PATCH RT 11/15] iommu/amd: Use raw_cpu_ptr() instead of get_cpu_ptr() for ->flush_queue

4.9.65-rt57-rc2 stable review patch. If anyone has any objections, please let me know. -- From: Sebastian Andrzej Siewior get_cpu_ptr() disabled preemption and returns the ->flush_queue object of the current CPU. raw_cpu_ptr() does the same except that it

[PATCH RT 12/15] iommu/amd: Use raw_cpu_ptr() instead of get_cpu_ptr() for ->flush_queue

4.9.65-rt57-rc1 stable review patch. If anyone has any objections, please let me know. -- From: Sebastian Andrzej Siewior get_cpu_ptr() disabled preemption and returns the ->flush_queue object of the current CPU. raw_cpu_ptr() does the same except that it

[PATCH RT 12/15] iommu/amd: Use raw_cpu_ptr() instead of get_cpu_ptr() for ->flush_queue

4.9.65-rt57-rc1 stable review patch. If anyone has any objections, please let me know. -- From: Sebastian Andrzej Siewior get_cpu_ptr() disabled preemption and returns the ->flush_queue object of the current CPU. raw_cpu_ptr() does the same except that it

Re: [PATCH] drivers/iommu: don't select DEBUG_FS for AMD_IOMMU_STATS

On Tue, 5 Apr 2016 17:19:51 +0200 Joerg Roedel wrote: > On Sat, Mar 26, 2016 at 09:18:44PM -0400, Paul Gortmaker wrote: > > We have at least one big banner telling people that they should > > not deploy production kernels with DEBUG options enabled, but > > at the same time, we

Re: [PATCH V3 2/2] debugfs: don't assume sizeof(bool) to be 4 bytes

On Tue, 15 Sep 2015 10:38:32 -0700 Linus Torvalds wrote: > But that user interface issue doesn't seem to be the case here, an I > can't say that I mind the patch. It looks fairly sane. If Linus is fine with it, I'm fine with it too. But please, next time, go

Re: [PATCH V3 2/2] debugfs: don't assume sizeof(bool) to be 4 bytes

On Tue, 15 Sep 2015 14:04:59 +0530 Viresh Kumar wrote: > diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c > index 2614a839c60d..f11e17ad7834 100644 > --- a/drivers/acpi/ec.c > +++ b/drivers/acpi/ec.c > @@ -1237,7 +1237,7 @@ ec_parse_device(acpi_handle handle, u32

Re: [PATCH V3 2/2] debugfs: don't assume sizeof(bool) to be 4 bytes

On Tue, 15 Sep 2015 16:34:47 +0530 Viresh Kumar wrote: > Hi Johannes, > > On 15-09-15, 12:37, Johannes Berg wrote: > > This email has far too many people Cc'ed on it - I don't think vger is > > even accepting it for that reason. You should probably restrict it to > >