Messages in this thread | | | Date | Mon, 20 Jun 2022 11:07:20 -0400 | From | Kent Overstreet <> | Subject | Re: [PATCH v4 00/34] Printbufs - new data structure for building strings |
| |
On Mon, Jun 20, 2022 at 04:19:31AM +0000, David Laight wrote: > From: Kent Overstreet > > Rasmus pointed out that -fno-strict-aliasing is going to cause gcc to generate > > nasty code, and indeed it unfortunately does but according to worst case > > scenario microbenchmarks it's not a problem for actual performance. > > Just copy some of the structure members to local variables > and, if necessary, write them back at the end.
You must not have read any of the code - half the point of this patch series is implementing proper helpers for printing chars, strings of bytes, etc. and that doesn't work if we're not using actual types.
> > printk("%pd", dentry); > > > > becomes > > > > printk("%pf(%p)", prt_dentry, dentry); > > > > My OOM debugging & reporting patch series that builds off of this uses this > > to solve a very real problem that Michal Hocko brought up at LSF - with this > > we write shrinkers_to_text(), slab_to_text() which can _also_ now be used for > > reporting in debugfs (which Roman has been working on), as well as in the > > show_mem() report - the "%pf()" syntax lets us print the output of those > > functions without allocating (and having to preallocate) a separate buffer. > > I really think that is a bad idea. > printk() already uses a lot of stack, anything doing a recursive > call is just making that worse. > Especially since these calls can often be in error paths > which are not often tested and can already be on deep stacks.
We went over this before - this patch series drastically reduces stack usage of sprintf by eliminating a bunch of stack allocated buffers. Do try to keep up...
| |